Forum: Ruby ClassMethods: Module creation hook / Capitalized method

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
transfire (Guest)
on 2005-11-30 15:36
(Received via mailing list)
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.
dblack (Guest)
on 2005-11-30 17:42
(Received via mailing list)
Hi --

On Wed, 30 Nov 2005, Trans wrote:

> 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.)

>
>  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
transfire (Guest)
on 2005-11-30 19:36
(Received via mailing list)
David A. Black wrote:
> 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/...

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.
dblack (Guest)
on 2005-11-30 20:12
(Received via mailing list)
Hi --

On Thu, 1 Dec 2005, Trans wrote:

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

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
transfire (Guest)
on 2005-11-30 20:16
(Received via mailing list)
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.
This topic is locked and can not be replied to.