From: Robert Dober <robert.dober@...>
Date: 2007-09-02T08:31:52+09:00
Subject: Re: Singleton Modules rather than Singleton Classes

On 9/1/07, dblack@wobblini.net <dblack@wobblini.net> wrote:
> Hi --
>
> On Sun, 2 Sep 2007, Logan Capaldo wrote:
>
> > On 9/1/07, Trans <transfire@gmail.com> wrote:
> >> 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)
>    RUBY FOR RAILS (http://www.manning.com/black)
> * Ruby/Rails training
>      & consulting:  Ruby Power and Light, LLC (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
>


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