2007/9/13, Trans <transfire / gmail.com>:
>
>
> On Sep 13, 1:59 am, "Robert Klemme" <shortcut... / googlemail.com>
> wrote:
> > 2007/9/12, Trans <transf... / gmail.com>:
> >
> >
> >
> > > On Sep 11, 1:55 am, "Robert Klemme" <shortcut... / googlemail.com>
> > > 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

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