# Singleton Modules rather than Singleton Classes **URL:** \ **Category:** ruby-talk\ **Created:** [1 September 2007 17:11 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321 "2007-09-01T17:11:32Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![7rans](https://avatars.discourse-cdn.com/v4/letter/7/a8b319/32.png) [@7rans](https://rubytalk.org/u/7rans)\ **Post date:** [1 September 2007 17:11 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/1 "2007-09-01T17:11:32Z")
This recently came up in the thread entitled "Python-style Decorators", so I thought it a fair idea to "formally" put it before the Ruby community. Here's the deal... Singleton classes already have more in common with modules than classes by the very behaviors that distinguish a module from a class -- they cannot be instantiated and they can not be inherited. So why exactly do we deem them classes at all? If instead we took them to be actual modules, and used as such, it would open up some really nice possibilities. For example:   class A     def self.x       "x"     end   end   class B     extend (class \<\< A; self; end)   end   B.x #=\> "x" This makes it dead simple to pass along module class-level methods in the class hierarchy. The immediate use of this change is apparent --no more ClassMethods/included callback hacks required. One thing to note about this example, the notation "(class \<\< A; self; end)" becomes a bit of a misnomer in light of the suggested change. "A.singleton" or some other method name, would be far better. Another possibility, which derives from the aforementioned thread, are method decorators using singleton def notation:   class Example     def memoized.foo       ...     end   end It is not possible to meta-code this currently b/c the definition of foo gets locked away in a singleton class where it can not be reused. If that singleton could be included into a class (in this case Example) then presto, problem solved, and a powerful new notation is opened up to the Ruby programmer. T. ---
**Author:** ![Logan\_Capaldo](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@Logan\_Capaldo](https://rubytalk.org/u/Logan_Capaldo)\ **Post date:** [1 September 2007 20:14 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/2 "2007-09-01T20:14:51Z")
> This recently came up in the thread entitled "Python-style > Decorators", so I thought it a fair idea to "formally" put it before > the Ruby community. Here's the deal... > > Singleton classes already have more in common with modules than > classes by the very behaviors that distinguish a module from a class -- > they cannot be instantiated and they can not be inherited. So why > exactly do we deem them classes at all? If instead we took them to be > actual modules, and used as such, it would open up some really nice > possibilities. For example: Counter proposal: remove singleton classes all together in favor of simply having singleton methods. The useful facility of a singleton class is that it allows you to have per-object methods (singleton methods). Class and module are both misnomers for the "thing that acts as a place to store singleton methods." By eliminating the visibility of this implementation detail, it allows for other implementations to be experimented with. The more you pin down how singleton methods are implemented, and the more you start doing things with details of that implementation the hard it becomes to have flexibility in that implementation. This also removes the need to justify referring to them as classes, and the false expectations this creates. My 2cents.. > **···** > > On 9/1/07, Trans \ wrote: > > > ---
**Author:** ![Robert\_K1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/robert_k1/32/1830_2.png) [@Robert\_K1](https://rubytalk.org/u/Robert_K1)\ **Post date:** [11 September 2007 08:55 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/3 "2007-09-11T08:55:17Z")
> This recently came up in the thread entitled "Python-style > Decorators", so I thought it a fair idea to "formally" put it before > the Ruby community. Here's the deal... > > Singleton classes already have more in common with modules than > classes by the very behaviors that distinguish a module from a class -- > they cannot be instantiated and they can not be inherited. So why > exactly do we deem them classes at all? If instead we took them to be > actual modules, and used as such, it would open up some really nice > possibilities. For example: > >   class A >     def self.x >       "x" >     end >   end > >   class B >     extend (class \<\< A; self; end) >   end > >   B.x #=\> "x" > > This makes it dead simple to pass along module class-level methods in > the class hierarchy. The immediate use of this change is apparent --no > more ClassMethods/included callback hacks required. You do not need that, because the functionality is there already: $ ruby \<\ class A >    def self.x >      "x" >    end > end > class B \< A; end > p B.x > XXX "x" > One thing to note about this example, the notation "(class \<\< A; self; > end)" becomes a bit of a misnomer in light of the suggested change. > "A.singleton" or some other method name, would be far better. > > Another possibility, which derives from the aforementioned thread, are > method decorators using singleton def notation: > >   class Example > >     def memoized.foo >       ... >     end > >   end > > It is not possible to meta-code this currently b/c the definition of > foo gets locked away in a singleton class where it can not be reused. > If that singleton could be included into a class (in this case > Example) then presto, problem solved, and a powerful new notation is > opened up to the Ruby programmer. I'd generally prefer to define modules explicitly and extend classes with them as Ara suggested. IMHO that's a cleaner way to achieve what you want and it also documents things more nicely (especially you can look at inheritance etc.). My 0.02EUR Kind regards robert > **···** > > 2007/9/1, Trans \: ---
**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:** [1 September 2007 20:42 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/4 "2007-09-01T20:42:06Z")
Hi -- > > This recently came up in the thread entitled "Python-style > > Decorators", so I thought it a fair idea to "formally" put it before > > the Ruby community. Here's the deal... > > > > Singleton classes already have more in common with modules than > > classes by the very behaviors that distinguish a module from a class -- > > they cannot be instantiated and they can not be inherited. So why > > exactly do we deem them classes at all? If instead we took them to be > > actual modules, and used as such, it would open up some really nice > > possibilities. For example: > > Counter proposal: remove singleton classes all together in favor of > simply having singleton methods. The useful facility of a singleton > class is that it allows you to have per-object methods (singleton > methods). Class and module are both misnomers for the "thing that acts > as a place to store singleton methods." By eliminating the visibility > of this implementation detail, it allows for other implementations to > be experimented with. The more you pin down how singleton methods are > implemented, and the more you start doing things with details of that > implementation the hard it becomes to have flexibility in that > implementation. This also removes the need to justify referring to > them as classes, and the false expectations this creates. My 2cents.. But then you introduce a whole second model of how method lookup and so forth works. What's nice about singleton classes is that they fit into the same basic model as other classes; once the premise is granted that every object can have a singleton class as well as a "birth" class, it all flows from there. I like the fact that every method lives in a class or module. I would actually be happy for them to be singleton modules instead of classes, though I don't really like the idea that one object can extend itself with another object's singleton methods. Or, to put it another way, I do like the possibility of strictly per-object behavior, so I wouldn't want to see that done away with. Maybe if it were done explicitly via dup'ing of some kind it would be OK. Otherwise it's just multiple objects sharing a module, which is basically what the non-singleton scenario already is. David > **···** > > On Sun, 2 Sep 2007, Logan Capaldo wrote: > > > On 9/1/07, Trans \ wrote: > > -- > \* Books: >    RAILS ROUTING (new! [http://www.awprofessional.com/title/0321509242\](http://www.awprofessional.com/title/0321509242%5C)) >    RUBY FOR RAILS ([http://www.manning.com/black\](http://www.manning.com/black%5C)) > \* Ruby/Rails training >      & consulting: Ruby Power and Light, LLC ([http://www.rubypal.com](http://www.rubypal.com)) ---
**Author:** ![a11](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/a11/32/8169_2.png) [@a11](https://rubytalk.org/u/a11)\ **Post date:** [10 September 2007 17:46 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/5 "2007-09-10T17:46:45Z")
i think i've done as much meta-programming as anyone out there and i would not like to see that chance. the reason is that the singleton\_class is also a nice place to store \*state\* - not only methods - when doing deep ruby magic. otherwise the whole affair of transforming singleton classes into modules seems reasonable but superfluous to me: it's just so easy to do module M; def x() 'x' end; end class A; extend M; end class B; extend M; end B.x #=\> 'x' that is hardly seems worth all the c coding and inevitable bugs even though the idea seems sounds. maybe 2.0? 2cts. a @ [http://drawohara.com/](http://drawohara.com/) > **···** > > On Sep 1, 2007, at 2:14 PM, Logan Capaldo wrote: > > > Counter proposal: remove singleton classes all together in favor of > > simply having singleton methods. The useful facility of a singleton > > class is that it allows you to have per-object methods (singleton > > methods). Class and module are both misnomers for the "thing that acts > > as a place to store singleton methods." By eliminating the visibility > > of this implementation detail, it allows for other implementations to > > be experimented with. The more you pin down how singleton methods are > > implemented, and the more you start doing things with details of that > > implementation the hard it becomes to have flexibility in that > > implementation. This also removes the need to justify referring to > > them as classes, and the false expectations this creates. My 2cents.. > > -- > we can deny everything, except that we have the possibility of being better. simply reflect on that. > h.h. the 14th dalai lama ---
**Author:** ![7rans](https://avatars.discourse-cdn.com/v4/letter/7/a8b319/32.png) [@7rans](https://rubytalk.org/u/7rans)\ **Post date:** [12 September 2007 18:06 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/6 "2007-09-12T18:06:10Z")
That is simply not correct. Fist of all, you do not control all code, so you can not make someone else modularized their module's class- level methods, so you can later augment them with meta-code. Secondly, the primary point has nothing to do with the fact that one can manage workarounds, of course there are ways, but b/c of limitations they are fragile and inefficient. Lastly, you are missing the point when you you say, "prefer to define modules explicitly... that's a cleaner way to achieve what you want". That's not the issue. Again, I encourage you to have a look as Facets' inheritor.rb lib to get a better understanding of this. T. > **···** > > On Sep 11, 1:55 am, "Robert Klemme" \ wrote: > > > I'd generally prefer to define modules explicitly and extend classes > > with them as Ara suggested. IMHO that's a cleaner way to achieve what > > you want and it also documents things more nicely (especially you can > > look at inheritance etc.). My 0.02EUR ---
**Author:** ![Forum](https://avatars.discourse-cdn.com/v4/letter/f/43a26b/32.png) [@Forum](https://rubytalk.org/u/Forum)\ **Post date:** [1 September 2007 23:31 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/7 "2007-09-01T23:31:52Z")
> Hi -- > > \>\> This recently came up in the thread entitled "Python-style > \>\> Decorators", so I thought it a fair idea to "formally" put it before > \>\> the Ruby community. Here's the deal... > \>\> > \>\> Singleton classes already have more in common with modules than > \>\> classes by the very behaviors that distinguish a module from a class -- > \>\> they cannot be instantiated and they can not be inherited. So why > \>\> exactly do we deem them classes at all? If instead we took them to be > \>\> actual modules, and used as such, it would open up some really nice > \>\> possibilities. For example: > \>\> > \> > \> Counter proposal: remove singleton classes all together in favor of > \> simply having singleton methods. The useful facility of a singleton > \> class is that it allows you to have per-object methods (singleton > \> methods). Class and module are both misnomers for the "thing that acts > \> as a place to store singleton methods." By eliminating the visibility > \> of this implementation detail, it allows for other implementations to > \> be experimented with. The more you pin down how singleton methods are > \> implemented, and the more you start doing things with details of that > \> implementation the hard it becomes to have flexibility in that > \> implementation. This also removes the need to justify referring to > \> them as classes, and the false expectations this creates. My 2cents.. > > But then you introduce a whole second model of how method lookup and > so forth works. What's nice about singleton classes is that they fit > into the same basic model as other classes; once the premise is > granted that every object can have a singleton class as well as a > "birth" class, it all flows from there. I like the fact that every > method lives in a class or module. > > I would actually be happy for them to be singleton modules instead of > classes, though I don't really like the idea that one object can > extend itself with another object's singleton methods. Or, to put it > another way, I do like the possibility of strictly per-object > behavior, so I wouldn't want to see that done away with. Maybe if it > were done explicitly via dup'ing of some kind it would be OK. > Otherwise it's just multiple objects sharing a module, which is > basically what the non-singleton scenario already is. > > David > > -- > \* Books: >    RAILS ROUTING (new! [http://www.awprofessional.com/title/0321509242\](http://www.awprofessional.com/title/0321509242%5C)) >    RUBY FOR RAILS ([http://www.manning.com/black\](http://www.manning.com/black%5C)) > \* Ruby/Rails training >      & consulting: Ruby Power and Light, LLC ([http://www.rubypal.com](http://www.rubypal.com)) All three proposals make sense to me, what does not make sense to me is the current state of affairs, as long as instance\_eval{   def a; @a end } works on arbitrary objects I will stay confused ;). It probably all depends on what kind of OO Style one prefers, Personally I would be looking forward to some serious simplifications, like e.g. \* Any unbound method can be bound to any object. \* Methods and Blocks could be unified. \* Method definitions in classes behave as in Modules. \* define\_method defines a method on any object \* define\_instance\_method defines an instance method on any object. \* Any object can have instances. (well and classes just went away) Well just some ideas more 😉 Robert > **···** > > On 9/1/07, dblack@wobblini.net \ wrote: > > > On Sun, 2 Sep 2007, Logan Capaldo wrote: > > \> On 9/1/07, Trans \ wrote: > > -- > I'm an atheist and that's it. I believe there's nothing we can know > except that we should be kind to each other and do what we can for > other people. > -- Katharine Hepburn ---
**Author:** ![Logan\_Capaldo](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@Logan\_Capaldo](https://rubytalk.org/u/Logan_Capaldo)\ **Post date:** [10 September 2007 22:32 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/8 "2007-09-10T22:32:16Z")
Care to give an example? > **···** > > On 9/10/07, ara.t.howard \ wrote: > > > \> i think i've done as much meta-programming as anyone out there and i > > would not like to see that chance. the reason is that the > > singleton\_class is also a nice place to store \*state\* - not only > > methods - when doing deep ruby magic. ---
**Author:** ![Robert\_K1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/robert_k1/32/1830_2.png) [@Robert\_K1](https://rubytalk.org/u/Robert_K1)\ **Post date:** [13 September 2007 08:59 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/9 "2007-09-13T08:59:29Z")
> \> I'd generally prefer to define modules explicitly and extend classes > \> with them as Ara suggested. IMHO that's a cleaner way to achieve what > \> you want and it also documents things more nicely (especially you can > \> look at inheritance etc.). My 0.02EUR > > That is simply not correct. Fist of all, you do not control all code, > so you can not make someone else modularized their module's class- > level methods, so you can later augment them with meta-code. I'm not sure. If they are not modularized I probably would not want to reuse them. > Secondly, > the primary point has nothing to do with the fact that one can manage > workarounds, of course there are ways, but b/c of limitations they are > fragile and inefficient. I don' t think inheriting (as show in my first reply) is fragile or inefficient but I may of course get in the way with other inheritance you'd want to do. > Lastly, you are missing the point when you > you say, "prefer to define modules explicitly... that's a cleaner way > to achieve what you want". That's not the issue. Again, I encourage > you to have a look as Facets' inheritor.rb lib to get a better > understanding of this. Um, you got me stumped here: in your original post you advertised easier reuse of singleton methods by making the singleton class a singleton module instead. Where exactly am I missing the point? Kind regards robert > **···** > > 2007/9/12, Trans \: > > > On Sep 11, 1:55 am, "Robert Klemme" \ \> wrote: ---
**Author:** ![Wayne\_E\_Seguin](https://avatars.discourse-cdn.com/v4/letter/w/d26b3c/32.png) [@Wayne\_E\_Seguin](https://rubytalk.org/u/Wayne_E_Seguin)\ **Post date:** [10 September 2007 15:38 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/10 "2007-09-10T15:38:58Z")
Bump! I'd like to hear the view of Matz on these ideas?    ~Wayne s///g Wayne E. Seguin Sr. Systems Architect & Systems Administrator > **···** > > On Sep 01, 2007, at 19:31 , Robert Dober wrote: > > > \ > > All three proposals make sense to me, what does not make sense to me > > is the current state of affairs, as long as > > instance\_eval{ > >   def a; @a end > > } > > works on arbitrary objects I will stay confused ;). > > It probably all depends on what kind of OO Style one prefers, > > Personally I would be looking forward to some serious simplifications, like e.g. > > \* Any unbound method can be bound to any object. > > \* Methods and Blocks could be unified. > > \* Method definitions in classes behave as in Modules. > > \* define\_method defines a method on any object > > \* define\_instance\_method defines an instance method on any object. > > \* Any object can have instances. (well and classes just went away) > > > > Well just some ideas more 😉 > > > > Robert ---
**Author:** ![a11](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/a11/32/8169_2.png) [@a11](https://rubytalk.org/u/a11)\ **Post date:** [11 September 2007 03:16 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/11 "2007-09-11T03:16:52Z")
sure. file: traits.rb ... 8 class Object 9 #--{{{ 10 def singleton\_method\_added(\*a, &b) 11 #--{{{ 12 ret = super rescue nil 13 obj = self 14 obj.\_\_trait\_singleton\_class.\_\_trait\_module\_eval{ @\_\_trait\_singleton\_super = obj } 15 ret 16 #--}}} 17 end ... this object is used in the search path: traits implements attr like methods with inheritance. a @ [http://drawohara.com/](http://drawohara.com/) > **···** > > On Sep 10, 2007, at 4:32 PM, Logan Capaldo wrote: > > > Care to give an example? > > -- > we can deny everything, except that we have the possibility of being better. simply reflect on that. > h.h. the 14th dalai lama ---
**Author:** ![7rans](https://avatars.discourse-cdn.com/v4/letter/7/a8b319/32.png) [@7rans](https://rubytalk.org/u/7rans)\ **Post date:** [13 September 2007 12:11 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/12 "2007-09-13T12:11:35Z")
> \> \> I'd generally prefer to define modules explicitly and extend classes > \> \> with them as Ara suggested. IMHO that's a cleaner way to achieve what > \> \> you want and it also documents things more nicely (especially you can > \> \> look at inheritance etc.). My 0.02EUR > > \> That is simply not correct. Fist of all, you do not control all code, > \> so you can not make someone else modularized their module's class- > \> level methods, so you can later augment them with meta-code. > > I'm not sure. If they are not modularized I probably would not want > to reuse them. Lots of libs define class singleton methods, none of them are modularized. > \> Secondly, > \> the primary point has nothing to do with the fact that one can manage > \> workarounds, of course there are ways, but b/c of limitations they are > \> fragile and inefficient. > > I don' t think inheriting (as show in my first reply) is fragile or > inefficient but I may of course get in the way with other inheritance > you'd want to do. Sorry, it's my fault. I should have made A a module in my original example to demonstrate better. The inheritance of your example isn't the difficulty. It's not class to class inheritance that makes things tricky, it's the modules. Which is what leads us to use ClassMethods modules and included callbacks. Generally, the more meta-code one must use (or just plan code for that matter) the more fragile a solution. And really, when we are depending on a callback to achieve a common pattern, that's a sure sign that something is amiss. > \> Lastly, you are missing the point when you > \> you say, "prefer to define modules explicitly... that's a cleaner way > \> to achieve what you want". That's not the issue. Again, I encourage > \> you to have a look as Facets' inheritor.rb lib to get a better > \> understanding of this. > > Um, you got me stumped here: in your original post you advertised > easier reuse of singleton methods by making the singleton class a > singleton module instead. Where exactly am I missing the point? Because it's not a matter of preference. There is no choice. The only way to currently achieve class-level class-\>module-\>class inheritance is through secondary modules and meta-coding. And I certainly don't see how being required to create an artificial abstraction (for example, ClassMethods) leads to cleaner code. Besides, no amount of meta-coding and secondary modules will allow for "fluent singleton notation" at all. Eg.   def memoized.foo     ...   end T. > **···** > > On Sep 13, 1:59 am, "Robert Klemme" \ wrote: > > > 2007/9/12, Trans \: > > \> On Sep 11, 1:55 am, "Robert Klemme" \ \> \> wrote: ---
**Author:** ![Logan\_Capaldo](https://avatars.discourse-cdn.com/v4/letter/l/7ea924/32.png) [@Logan\_Capaldo](https://rubytalk.org/u/Logan_Capaldo)\ **Post date:** [11 September 2007 10:28 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/13 "2007-09-11T10:28:56Z")
> \> Care to give an example? > > sure. > > file: traits.rb > ... > 8 class Object > 9 #--{{{ > 10 def singleton\_method\_added(\*a, &b) > 11 #--{{{ > 12 ret = super rescue nil > 13 obj = self > 14 obj.\_\_trait\_singleton\_class.\_\_trait\_module\_eval > { @\_\_trait\_singleton\_super = obj } > 15 ret > 16 #--}}} > 17 end > ... I assume \_\_trait\_singleton\_class is (class \<\< obj; self; end) and \_\_trait\_module\_module is a wrapper around module\_eval? You can do this without ivars, just define a \_\_trait\_singleton\_super singleton method that returns obj, Or you can do it with ivars but keep the ivar in the object instead of the singleton class. > **···** > > On 9/10/07, ara.t.howard \ wrote: > > > On Sep 10, 2007, at 4:32 PM, Logan Capaldo wrote: > > > this object is used in the search path: traits implements attr like > > methods with inheritance. > > > > a @ [http://drawohara.com/](http://drawohara.com/) > > -- > > we can deny everything, except that we have the possibility of being > > better. simply reflect on that. > > h.h. the 14th dalai lama ---
**Author:** ![Robert\_K1](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/robert_k1/32/1830_2.png) [@Robert\_K1](https://rubytalk.org/u/Robert_K1)\ **Post date:** [14 September 2007 06:45 UTC](https://rubytalk.org/t/singleton-modules-rather-than-singleton-classes/40321/14 "2007-09-14T06:45:06Z")
Thanks for the explanation! I think I got a better picture now. Another side note: I thought I remember there was a way to get two instances with the same singleton class but apparently I cannot reproduce it. Even if, that case was probably so esoteric that it is no obstacle to changing singleton classes to singleton modules. (And while that happens we should also introduce a method to access it.) Kind regards robert > **···** > > 2007/9/13, Trans \: > > > On Sep 13, 1:59 am, "Robert Klemme" \ \> wrote: > > \> 2007/9/12, Trans \: > > \> > > \> > > \> > > \> \> On Sep 11, 1:55 am, "Robert Klemme" \ \> \> \> wrote: > > \> > > \> \> \> I'd generally prefer to define modules explicitly and extend classes > > \> \> \> with them as Ara suggested. IMHO that's a cleaner way to achieve what > > \> \> \> you want and it also documents things more nicely (especially you can > > \> \> \> look at inheritance etc.). My 0.02EUR > > \> > > \> \> That is simply not correct. Fist of all, you do not control all code, > > \> \> so you can not make someone else modularized their module's class- > > \> \> level methods, so you can later augment them with meta-code. > > \> > > \> I'm not sure. If they are not modularized I probably would not want > > \> to reuse them. > > > > Lots of libs define class singleton methods, none of them are > > modularized. > > > > \> \> Secondly, > > \> \> the primary point has nothing to do with the fact that one can manage > > \> \> workarounds, of course there are ways, but b/c of limitations they are > > \> \> fragile and inefficient. > > \> > > \> I don' t think inheriting (as show in my first reply) is fragile or > > \> inefficient but I may of course get in the way with other inheritance > > \> you'd want to do. > > > > Sorry, it's my fault. I should have made A a module in my original > > example to demonstrate better. The inheritance of your example isn't > > the difficulty. It's not class to class inheritance that makes things > > tricky, it's the modules. Which is what leads us to use ClassMethods > > modules and included callbacks. Generally, the more meta-code one must > > use (or just plan code for that matter) the more fragile a solution. > > And really, when we are depending on a callback to achieve a common > > pattern, that's a sure sign that something is amiss. > > > > \> \> Lastly, you are missing the point when you > > \> \> you say, "prefer to define modules explicitly... that's a cleaner way > > \> \> to achieve what you want". That's not the issue. Again, I encourage > > \> \> you to have a look as Facets' inheritor.rb lib to get a better > > \> \> understanding of this. > > \> > > \> Um, you got me stumped here: in your original post you advertised > > \> easier reuse of singleton methods by making the singleton class a > > \> singleton module instead. Where exactly am I missing the point? > > > > Because it's not a matter of preference. There is no choice. The only > > way to currently achieve class-level class-\>module-\>class inheritance > > is through secondary modules and meta-coding. And I certainly don't > > see how being required to create an artificial abstraction (for > > example, ClassMethods) leads to cleaner code. > > > > Besides, no amount of meta-coding and secondary modules will allow for > > "fluent singleton notation" at all. Eg. > > > >   def memoized.foo > >     ... > >   end