ClassMethods: Module creation hook / Capitalized method

[Trans]

I'm sure everyone knows about the ClassMethods technique for getting a
module's class/module methods to be inherited. I have come up with an
improvement on this, but rather than define a ClassMehthods module
manually one supplies a block to a method. It still creates the
ClassMethods module, but it does so using the block. If there were a
way to hook into module creation that wouldn't be neccessary. But is
there a way to hook into this?

On the other hand sticking with the block method, I realized I could
use a capitalized method name without inherfereing witht the module
(they exist in separate namespaces). So..

module Foo

ClassMethods do
def x ; 1 ; end
end

end

class Bar ; include Foo ; end

Bar.x #=> 1

Using a capitalized method like this, is it a good idea b/c it
corresponds to the module name, or a bad idea b/c it does against
convention?

Note how the above is equivalent to:

module Foo

module ClassMethods
def x ; 1 ; end
end

extend ClassMethods

end

The block method does the extending for you.


Thanks,
T.

 

[David A. Black]

Hi --

I'm sure everyone knows about the ClassMethods technique for getting a
module's class/module methods to be inherited.

I didn't know there was a widely-known or standard technique of that
name (and I wouldn't use the term "inherited" to describe what happens
to methods in modules; it muddies the waters a bit), but if you mean
the kind of thing that's done in ActiveRecord and related libraries to
promote instance methods of a module to pseudo-class-methods of
classes that include the module's containing module, then yes
(I say "pseudo" because they're not actually class methods, but they
end up being useable as if they were.)

I have come up with an
improvement on this, but rather than define a ClassMehthods module
manually one supplies a block to a method. It still creates the
ClassMethods module, but it does so using the block. If there were a
way to hook into module creation that wouldn't be neccessary. But is
there a way to hook into this?

On the other hand sticking with the block method, I realized I could
use a capitalized method name without inherfereing witht the module
(they exist in separate namespaces). So..

module Foo

ClassMethods do
def x ; 1 ; end
end

I think the pseudo-ness of the class method-ness of these methods is
an issue here. You're really redefining the notion of a class method;
it's no longer a singleton method of a class object. I imagine
some counter-argument involving the word "duck" could probably be
developed... But I'm personally not a big fan of just asserting
that something is a class method when that's really not the right term
for it. (I have the same problem with the ClassMethods module
technique. It works by a kind of consensus, but I don't consider it
an optimal naming scheme.)

end

class Bar ; include Foo ; end

Bar.x #=> 1

Using a capitalized method like this, is it a good idea b/c it
corresponds to the module name, or a bad idea b/c it does against
convention?

I'm confused -- do you have a ClassMethods module lurking somewhere?


David

 

[Trans]

I didn't know there was a widely-known or standard technique of that
name (and I wouldn't use the term "inherited" to describe what happens
to methods in modules; it muddies the waters a bit), but if you mean
the kind of thing that's done in ActiveRecord and related libraries to
promote instance methods of a module to pseudo-class-methods of
classes that include the module's containing module, then yes
(I say "pseudo" because they're not actually class methods, but they
end up being useable as if they were.)

We've talked about this before. And I'm not sure we need to get into it
again, but I don't see how you say they are not class methods when the
module is being included (extended) into the class adhoc (i.e. it's
singleton).

I think the pseudo-ness of the class method-ness of these methods is
an issue here. You're really redefining the notion of a class method;
it's no longer a singleton method of a class object. I imagine
some counter-argument involving the word "duck" could probably be
developed...

But classes already work this way! How does allowing modules do the
same thing change any such notion?

But I'm personally not a big fan of just asserting
that something is a class method when that's really not the right term
for it. (I have the same problem with the ClassMethods module
technique. It works by a kind of consensus, but I don't consider it
an optimal naming scheme.)

Well ask Nodu about it, AFAIK he was the originator of the idea:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35979

Personally I had been calling it ClassInheritable (though you probably
think that's even worse) but since ClassMethods is commonly used I
figure it best to stick with whats known. I agree it may not be the
best name --a bit overly general IMO, but then again I think this
should be the default behavior in the first place and a seprate module
ought to be needed to NOT inherit along the singleton chain --as you
are aware frm the RCR.

I'm confused -- do you have a ClassMethods module lurking somewhere?

Presently you can find both ClassMethods and #class_inherit in the
latest Facets. These will be usurped by an improved melding of the two
available in Calibre, which I am tweaking presently which is why I
brought this thread up.

T.

 

[Trans]

Hmmm...it's just occured to me that others may have "tweaked out" there
usage of ClassMethods so my lib might cause interference --unlikely but
it could happen. So I think I'll rename it to be on the save side.
Thanks for making me think of that David.

T.

 

[David A. Black]

Hi --

Well ask Nodu about it, AFAIK he was the originator of the idea:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35979

OK: Nobu, don't you think there's a distinction between class methods
that are defined on one particular class, and methods that are
defined as instance methods in another context and made available to
many classes via a module?

I think it's partly a matter of there not being a language-level
definition of "class method" (which is actually OK with me). If there
were, I would tend to equate it with MyClass.singleton_methods(false),
rather than MyClass.singleton_methods. Maybe that's an artificial
distinction, though, from the perspective of the user.

Come to think of it, it's a bit odd that there's such a thing as an
object's "singleton" methods that aren't defined in the object's
singleton class. Maybe that's the lump under the carpet that doesn't
seem to want to disappear in all of this.


David