Hi --

On Sun, 24 Jun 2007, Rick DeNatale wrote:

> On 6/22/07, Gregory Brown <gregory.t.brown / gmail.com> wrote:
>> On 6/22/07, dblack / wobblini.net <dblack / wobblini.net> wrote:
>> 
>> > It's interesting, though, that Matz's reason for not adding K#s_c is,
>> > I think, concern about the name of the singleton class (as opposed to
>> > wanting it to be obscure).  Hopefully that will be clarified in 2.0.
>> 
>> Well at this point is anyone still vehemently opposed to singleton_class ?
>> 
>> Meta class seems to be falling out of fashion and Eigenclass (sadly)
>> never had widespread acceptance.
>
> The problem with metaclass is that it's just one of the two(?) uses of
> singleton class, a metaclass is the class of a class, which in ruby
> happens to be implemented by a singleton class.
>
> I'd suggest defining Kernel#singleton_class, AND defining
> Module#metaclass as an alias which applies to Modules and classes.   I
> THINK that it makes sense to think of the (singleton) class of a
> Module to be a metaclass.
>
> Were this done, another question arises as to whether e,g, Array.class
> should still return Class instead of
> #<Class:Array>.  To me this seems different than the case of hiding a
> singleton class of an object which is not a Module/Class.

The goal of #singleton_class, though, would be to un-hide the
singleton class, so #class would be free to report on the "birth
class" relieved of any responsibility to worry about the singleton.

I'm not sure about "metaclass" for classes' singleton classes, though
there's no doubt that the inheritance thing whereby a class can call
its superclass's singleton methods certainly makes the term
"singleton" a bit of an imperfect fit....


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)