# About class methods **URL:** \ **Category:** ruby-talk\ **Created:** [8 December 2005 06:30 UTC](https://rubytalk.org/t/about-class-methods/23105 "2005-12-08T06:30:00Z")\ **Posts on this page:** 16\ **Page:** 3
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [13 December 2005 04:06 UTC](https://rubytalk.org/t/about-class-methods/23105/41 "2005-12-13T04:06:42Z")
Martin DeMello wrote: > It's not a subclass, it's an anonymous proxy superclass. It goes into > the inheritance chain between the object it extends and the class that > object derived from, like so (assume a is a String): > > [String] --- [class \<\< a] --- [a] > > Since ruby doesn't have multiple inheritance, you can see why there can > (and need!) only be a single proxy superclass. So, this means you lose the functionality of a? I thought the whole point was to extend a. The tutorial ([http://www.rubygarden.org/ruby?SingletonTutorial\](http://www.rubygarden.org/ruby?SingletonTutorial%5C)) actually doesn't mention whether it is super or sub, i just assumed sub. I suppose whether it was super or sub really doesn't matter except in what you would be referencing by 'self' or 'super' in the added code (i.e., if you are correct, then doing self at class scope level would allow you to access the super class, or doing self at instance scope (in the new code) would reference an instance of the super class. Of course, if you used super in that context, it would reference the original class' grandparent. Are you sure this is how it works? The tutorial doesn't do any of the things I just mentioned, so it can't answer this question. Thanks, --J > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Gene\_Tani](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@Gene\_Tani](https://rubytalk.org/u/Gene_Tani)\ **Post date:** [13 December 2005 04:32 UTC](https://rubytalk.org/t/about-class-methods/23105/42 "2005-12-13T04:32:38Z")
Martin DeMello wrote: > **···** > > > "jonathan \ \ \" \ wrote: > > \> > > \> Hmm.. Ok. But, with Ruby, you can still dynamically create subclasses > > \> that aren't singletons and extend them as well as instanciate instances > > \> of them, right? That would provide the flexibility I was referring to > > \> above, but I suppose it would require typing quite a few more > > \> characters. So do I understand correctly that Matz designed the whole > > \> singleton creation mechanism ( \<\< ) as a shorthand for doing more > > \> long-winded dynamic creation/enhancing? > > > > It's not a subclass, it's an anonymous proxy superclass. It goes into > > the inheritance chain between the object it extends and the class that > > object derived from, like so (assume a is a String): > > > > [String] --- [class \<\< a] --- [a] > > > > Since ruby doesn't have multiple inheritance, you can see why there can > > (and need!) only be a single proxy superclass. > > > > martin > > How about this old chestnut, which I frankly don't understand: > > [http://onestepback.org/images/rubyobjects.png](http://onestepback.org/images/rubyobjects.png) ---
**Author:** ![Gary\_Wright](https://avatars.discourse-cdn.com/v4/letter/g/58956e/32.png) [@Gary\_Wright](https://rubytalk.org/u/Gary_Wright)\ **Post date:** [11 December 2005 04:05 UTC](https://rubytalk.org/t/about-class-methods/23105/43 "2005-12-11T04:05:09Z")
> Hmm. Ok, so there really is no singleton class for Myclass? In other > words, must the singleton always be associated with an instance and not > a class? In Ruby, a class \*is\* an instance. Specifically, a class is an instance of the class Class. So, yes, you can reference the singleton object of a class:   class \<\ Yea. That is cool, but can you still do something like this: > > class Myclass > end > > def extend\_class( some\_class ) >   code = %{ class #{some\_class.class}\_extension \< #{some\_class.class} >               def new\_method1 >               end >               ... >             end } >   eval( code ) > > extend\_class( Myclass ) > x = Myclass\_extension.new > x.new\_method1 > y = Myclass\_extension.new > y.new\_method1 I'm not sure what you are getting at here. Myclass.class is the particular object Class. Because all class objects are instances of Class.   #{some\_class.class}\_extension ends up being the string   Class\_extension because Class.to\_s is the string 'Class'. If you want to subclass and add methods just do it: class Myclass end class Subclass \< Myclass    def new\_method1    end end x = Subclass.new y = Subclass.new x.new\_method1 y.new\_method1 > **···** > > On Dec 10, 2005, at 8:34 PM, jonathan wrote: ---
**Author:** ![Anonymous\_Coward](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Anonymous\_Coward](https://rubytalk.org/u/Anonymous_Coward)\ **Post date:** [11 December 2005 05:09 UTC](https://rubytalk.org/t/about-class-methods/23105/44 "2005-12-11T05:09:23Z")
> dblack wrote: > \>\> Hmm.. Ok. But, with Ruby, you can still dynamically create subclasses > \>\> that aren't singletons and extend them as well as instanciate instances > \>\> of them, right? That would provide the flexibility I was referring to > \>\> above, but I suppose it would require typing quite a few more > \>\> characters. So do I understand correctly that Matz designed the whole > \>\> singleton creation mechanism ( \<\< ) as a shorthand for doing more > \>\> long-winded dynamic creation/enhancing? > \> > \> The starting-point of the whole thing is the principle that objects > \> can be individually extended. Two instances of MyClass, for example, > \> begin life with the same capabilities (methods), but during their > \> lives can diverge: > \> > \> class MyClass > \> end > \> > \> a = MyClass.new > \> b = MyClass.new > \> > \> def a.x > \> end > \> > \> def b.y > \> end > \> > \> The singleton class mechanism is just a way to store those "extra" > \> methods. The methods written for a (namely, "x") go in a's singleton > \> class; those for b, in b's; etc. These classes are created > \> automatically when they are needed. > > Hmm. Ok, so there really is no singleton class for Myclass? In other > words, must the singleton always be associated with an instance and not > a class? > > \> > \> If you want to open a class definition block for an object's singleton > \> class, you use the class keyword, plus "\<\< obj". This special syntax > \> is necessary because singleton classes are anonymous. Other than > \> that, it's very much like doing "class C". > \> > \> It's all very simple and elegant, isn't it? 🙂 > \> > > Yea. That is cool, but can you still do something like this: > > class Myclass > end > > def extend\_class( some\_class ) >   code = %{ class #{some\_class.class}\_extension \< #{some\_class.class} >               def new\_method1 >               end >               ... >             end } >   eval( code ) > > extend\_class( Myclass ) > x = Myclass\_extension.new > x.new\_method1 > y = Myclass\_extension.new > y.new\_method1 > > Some variation of this (where the extended class is named uniquely) > should allow infinitely many extended subclasses and also allow > non-singleton (i.e., many) instances of the subclasses. Typically, if I understand you correctly, you could just use this idiom (unless you want to just eval the whole thing):   # Classes are constants   # | Inherit MyClass   # | | We can use blocks   # | | |   # V V V   MyClassExtension = Class.new(MyClass) {                        def self.some\_method()                          # ...                        end                        def some\_method()                          # ...                        end                      } > Of course, I suppose you could start with x and y as instances of the > base class and add the new\_method's to each of them just as easily (and > with probably less typing). So, would there ever be a reason to do > something like I wrote above? > > --J E > **···** > > On 2005.12.11 10:34, "jonathan \ \ \ \" \ wrote: ---
**Author:** ![David\_A\_Black3](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_A\_Black3](https://rubytalk.org/u/David_A_Black3)\ **Post date:** [11 December 2005 20:19 UTC](https://rubytalk.org/t/about-class-methods/23105/45 "2005-12-11T20:19:59Z")
Hi -- > dblack wrote: > > > The singleton class mechanism is just a way to store those "extra" > > methods. The methods written for a (namely, "x") go in a's singleton > > class; those for b, in b's; etc. These classes are created > > automatically when they are needed. > > Hmm. Ok, so there really is no singleton class for Myclass? In other > words, must the singleton always be associated with an instance and not > a class? Every object (almost) can have a singleton class, including Class objects. > > If you want to open a class definition block for an object's singleton > > class, you use the class keyword, plus "\<\< obj". This special syntax > > is necessary because singleton classes are anonymous. Other than > > that, it's very much like doing "class C". > > > > It's all very simple and elegant, isn't it? 🙂 > > Yea. That is cool, but can you still do something like this: > > class Myclass > end > > def extend\_class( some\_class ) > code = %{ class #{some\_class.class}\_extension \< #{some\_class.class} >              def new\_method1 >              end >              ... >            end } > eval( code ) > > extend\_class( Myclass ) > x = Myclass\_extension.new > x.new\_method1 > y = Myclass\_extension.new > y.new\_method1 > > Some variation of this (where the extended class is named uniquely) > should allow infinitely many extended subclasses and also allow > non-singleton (i.e., many) instances of the subclasses. There are easier ways, such as (I think someone else pointed out) Class.new(superclass). Using eval is a stretch; in fact, I'm fairly confident in saying that it's almost a certain sign that you're doing something which can be done a cleaner way, or that perhaps needs to be rethought entirely. Anyway -- a non-eval version of what you've got above might be something like:    class MyClass    end    def extend\_class(classname)      ex = Object.const\_set(classname.to\_s + "\_extension", Class.new)      ex.class\_eval do         def new\_method1           puts "new method"         end       end    end    extend\_class(MyClass)    x = MyClass\_extension.new    x.new\_method1 > Of course, I suppose you could start with x and y as instances of the > base class and add the new\_method's to each of them just as easily (and > with probably less typing). So, would there ever be a reason to do > something like I wrote above? Probably not 🙂 But it's good to learn all of these permutations, I think. David > **···** > > On Sun, 11 Dec 2005, jonathan \ \ \ \ wrote: > > -- > David A. Black > dblack@wobblini.net > > "Ruby for Rails", forthcoming from Manning Publications, April 2006! ---
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [13 December 2005 04:09 UTC](https://rubytalk.org/t/about-class-methods/23105/46 "2005-12-13T04:09:42Z")
Oops. Nevermind the part about losing functionality. However, I think the discussion of self/super still applies. --J > **···** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [11 December 2005 05:08 UTC](https://rubytalk.org/t/about-class-methods/23105/47 "2005-12-11T05:08:05Z")
gwtmp01 wrote: > > extend\_class( Myclass ) > > x = Myclass\_extension.new > > x.new\_method1 > > y = Myclass\_extension.new > > y.new\_method1 > > I'm not sure what you are getting at here. > > Myclass.class is the particular object Class. Because > all class objects are instances of Class. > >   #{some\_class.class}\_extension > > ends up being the string > >   Class\_extension > > because Class.to\_s is the string 'Class'. Oops. It should have been #{some\_class}. The whole point of that was so that I could have code that writes code (dynamically) based on states of other parts of the program (I think it is also known as metaprogramming). Of course, with that simple example I posted, it wouldn't make much sense. It seems like this sort of thing would be very useful for artificial intelligence (i.e., learning). On the class singleton example you posted: that's very neat. Now, I think my understanding of these sort of singletons is complete. 🙂 --J > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [11 December 2005 05:25 UTC](https://rubytalk.org/t/about-class-methods/23105/48 "2005-12-11T05:25:46Z")
ruby-ml wrote: > **···** > > > On 2005.12.11 10:34, "jonathan \ \> \ \ \" \> \ wrote: > > > > > \> can be individually extended. Two instances of MyClass, for example, > > > \> end > > > words, must the singleton always be associated with an instance and not > > > > > >             end } > > > non-singleton (i.e., many) instances of the subclasses. > > > > Typically, if I understand you correctly, you could just use this > > idiom (unless you want to just eval the whole thing): > > > >   # Classes are constants > >   # | Inherit MyClass > >   # | | We can use blocks > >   # | | | > >   # V V V > >   MyClassExtension = Class.new(MyClass) { > >                        def self.some\_method() > >                          # ... > >                        end > > > >                        def some\_method() > >                          # ... > >                        end > >                      } > > Oooh. That's cool! In the case I was envisioning, I would want to eval > the whole thing (so that classes could be extended dynamically at > run-time). > > --J > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [12 December 2005 04:07 UTC](https://rubytalk.org/t/about-class-methods/23105/49 "2005-12-12T04:07:10Z")
unknown wrote: >    class MyClass >    end > >    def extend\_class(classname) >      ex = Object.const\_set(classname.to\_s + "\_extension", Class.new) >      ex.class\_eval do >         def new\_method1 >           puts "new method" >         end >       end >    end > >    extend\_class(MyClass) >    x = MyClass\_extension.new >    x.new\_method1 Oh. That's a neat way of doing it. Would the code below also work in order to support a dynamic method name?     class MyClass     end     def extend\_class(classname, methodname)       ex = Object.const\_set(classname.to\_s + "\_extension", Class.new)       ex.class\_eval %{          def #(methodname)            puts "new method"          end }        end     end --J > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [11 December 2005 05:16 UTC](https://rubytalk.org/t/about-class-methods/23105/50 "2005-12-11T05:16:36Z")
Actually, according to wikipedia, metaprogramming involves only rewrites done at compile time and not run-time (such as lex or yacc, which generate code). So, I guess this would simply be 'self-modifying' code. --J > **···** > > jonathan leonard \ \ > > (I think it is also known as > > metaprogramming). > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Eero\_Saynatkari1](https://avatars.discourse-cdn.com/v4/letter/e/46a35a/32.png) [@Eero\_Saynatkari1](https://rubytalk.org/u/Eero_Saynatkari1)\ **Post date:** [11 December 2005 15:51 UTC](https://rubytalk.org/t/about-class-methods/23105/51 "2005-12-11T15:51:56Z")
> ruby-ml wrote: > > > > \> can be individually extended. Two instances of MyClass, for example, > > > \> end > > > words, must the singleton always be associated with an instance and not > > > > > >             end } > > > non-singleton (i.e., many) instances of the subclasses. > > > > Typically, if I understand you correctly, you could just use this > > idiom (unless you want to just eval the whole thing): > > > >   # Classes are constants > >   # | Inherit MyClass > >   # | | We can use blocks > >   # | | | > >   # V V V > >   MyClassExtension = Class.new(MyClass) { > >                        def self.some\_method() > >                          # ... > >                        end > > > >                        def some\_method() > >                          # ... > >                        end > >                      } > > Oooh. That's cool! In the case I was envisioning, I would want to eval > the whole thing (so that classes could be extended dynamically at > run-time). Just to be clear (I think you have the right idea, but for the benefit of any future ruby miners), you can use the above construct dynamically at runtime. If you are doing a lot of dynamic method naming and such (a proposition of debateable merit as you would have to #send all your messages), it may be easier to use strings in conjunction with one of #(class|module|instance)\_eval. > --J E > **···** > > jonathan leonard \ \ > > > On 2005.12.11 10:34, "jonathan \ \>\> \ \ \" \>\> \ wrote: > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Anonymous\_Coward](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Anonymous\_Coward](https://rubytalk.org/u/Anonymous_Coward)\ **Post date:** [12 December 2005 04:20 UTC](https://rubytalk.org/t/about-class-methods/23105/52 "2005-12-12T04:20:23Z")
> unknown wrote: > > \> > \> class MyClass > \> end > \> > \> def extend\_class(classname) > \> ex = Object.const\_set(classname.to\_s + "\_extension", Class.new) > \> ex.class\_eval do > \> def new\_method1 > \> puts "new method" > \> end > \> end > \> end > \> > \> extend\_class(MyClass) > \> x = MyClass\_extension.new > \> x.new\_method1 > \> > > Oh. That's a neat way of doing it. Would the code below also work in > order to support a dynamic method name? > >     class MyClass >     end > >     def extend\_class(classname, methodname) >       ex = Object.const\_set(classname.to\_s + "\_extension", Class.new) >       ex.class\_eval %{ >          def #(methodname) >            puts "new method" >          end } >        end >     end Well, there is always define\_method:   # This code for illustrative purposes only. This is unadvisable.   class Class     def extend\_by(method\_name, &block)       o = Object.const\_set("#{self.name}Extension", Class.new(self))       o.class\_eval {         define\_method(method\_name, &block)       }       o     end   end   class Foo   end   Extension = Foo.extend\_by('quux') { puts "Hello from quux!" }   Extension.new.quux > --J E > **···** > > On 2005.12.12 13:07, "jonathan \ \ wrote: ---
**Author:** ![James\_Edward\_Gray\_II](https://avatars.discourse-cdn.com/v4/letter/j/ea5d25/32.png) [@James\_Edward\_Gray\_II](https://rubytalk.org/u/James_Edward_Gray_II)\ **Post date:** [11 December 2005 15:47 UTC](https://rubytalk.org/t/about-class-methods/23105/53 "2005-12-11T15:47:26Z")
That's not how we generally use it in the Ruby community, but keep in mind that Ruby greatly blurs the compile-time, run-time distinction. My buddy calls Unit Tests, Ruby's compile-time error checking. Hard to argue with that. 😉 James Edward Gray II > **···** > > On Dec 10, 2005, at 11:16 PM, jonathan leonard wrote: > > > jonathan leonard \ \ > > > > (I think it is also known as > > > metaprogramming). > > > > Actually, according to wikipedia, metaprogramming involves only rewrites > > done at compile time and not run-time (such as lex or yacc, which > > generate code). So, I guess this would simply be 'self-modifying' code. ---
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [13 December 2005 03:59 UTC](https://rubytalk.org/t/about-class-methods/23105/54 "2005-12-13T03:59:52Z")
Eero Saynatkari wrote: > Well, there is always define\_method: > >   # This code for illustrative purposes only. This is unadvisable. >   class Class >     def extend\_by(method\_name, &block) >       o = Object.const\_set("#{self.name}Extension", Class.new(self)) >       o.class\_eval { >         define\_method(method\_name, &block) >       } >       o >     end >   end > >   class Foo >   end > >   Extension = Foo.extend\_by('quux') { puts "Hello from quux!" } >   Extension.new.quux Why is the code above unadvisable? --J > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Eero\_Saynatkari1](https://avatars.discourse-cdn.com/v4/letter/e/46a35a/32.png) [@Eero\_Saynatkari1](https://rubytalk.org/u/Eero_Saynatkari1)\ **Post date:** [13 December 2005 04:26 UTC](https://rubytalk.org/t/about-class-methods/23105/55 "2005-12-13T04:26:42Z")
jonathan leonard wrote: > Eero Saynatkari wrote: > > > Well, there is always define\_method: > > > >   # This code for illustrative purposes only. This is unadvisable. > >   class Class > >     def extend\_by(method\_name, &block) > >       o = Object.const\_set("#{self.name}Extension", Class.new(self)) > >       o.class\_eval { > >         define\_method(method\_name, &block) > >       } > >       o > >     end > >   end > > > >   class Foo > >   end > > > >   Extension = Foo.extend\_by('quux') { puts "Hello from quux!" } > >   Extension.new.quux > > Why is the code above unadvisable? I personally think the idiom is a bit suspect but it could just be I have not come across the need for it 🙂 The above merely illustrates that it is quite possible to do that in ruby; however, another way might lead to a better design. (Generally, any types of factories are simple in ruby and the whole duck-typing thing helps, too.) > --J E > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Jonathan\_zjll9](https://avatars.discourse-cdn.com/v4/letter/j/858c86/32.png) [@Jonathan\_zjll9](https://rubytalk.org/u/Jonathan_zjll9)\ **Post date:** [13 December 2005 05:11 UTC](https://rubytalk.org/t/about-class-methods/23105/56 "2005-12-13T05:11:10Z")
Eero Saynatkari wrote: > > Why is the code above unadvisable? > > I personally think the idiom is a bit suspect but it could > just be I have not come across the need for it 🙂 The above > merely illustrates that it is quite possible to do that in > ruby; however, another way might lead to a better design. > > (Generally, any types of factories are simple in ruby and > the whole duck-typing thing helps, too.) I don't really see how duck-typing is relevant, but I would assume that the idiom used above (i.e., 'const\_set', 'class\_eval', and 'define\_method') could be done in an extension factory (rather than procedurally as above). In other words, you might have a factory called JumpExtensionFactory which could create any object that can jump (e.g., people, animals, monsters, etc.) from a non-jumping object say in a video game model. I suppose it would have to calculate the maximum jump height and length based on other statistics such as leg strength, weight, etc. (which would presumably have to be attributes the object already has or can acquire) and the actual jump height and length based on run-time attributes such as velocity and input force. That is the purpose I can see for this sort of thing. Is that what you mean by utilizing factories? The only real problem I see with this is you really wouldn't want to create a new object, but rather extend the original one. In other words, after a type learns to jump, then all objects of that type should be able to jump (so there's no need to distinguish from a non-jumping version and the jumping version). So, actually, I would call it an JumpExtender or a JumpTeacher (instead of JumpExtensionFactory). (Thinking out loud here). But, hopefully we're closer to the same page now. --J > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). [Previous page](https://rubytalk.org/t/about-class-methods/23105.md?page=2)