Error in ancestor?

[Rick DeNatale]

As for singleton classes: I still strongly root for
Kernel#singleton_class. ...
And it all falls into place except that you
have to go through the class << self; self; end thing to get at the
class, and that makes it feel like a second-class (ha ha) citizen.

To me it feels like I'm hiding out in the High School boy's room with
a cigarette. <G>

 

[dblack]

Hi --

To me it feels like I'm hiding out in the High School boy's room with
a cigarette. <G>

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.


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)

 

[Gregory Brown]

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.

I know there is discomfort with the Singleton pattern ambiguity, but I
don't think it's a big deal. Maybe some people still do.

 

[Joel VanderWerf]

To me it feels like I'm hiding out in the High School boy's room with
a cigarette. <G>

Now I know how to pronounce <<: it is the "cigarette" operator!

 

[Robert Dober]

Now I know how to pronounce <<: it is the "cigarette" operator!

Oh no, cannot use it anymore at work, forbidden by law
Robert

 

[Rick DeNatale]

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.

 

[dblack]

Hi --

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)

 

[Gregory Brown]

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.

+1, I think having #singleton_class removes any ambiguity of what #class is.

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

How about eigenclass? ((hides))

 

[Robert Dober]

+1, I think having #singleton_class removes any ambiguity of what #class is.

Kernel#singleton_class really looks fine to me, once we have this, we
will include the singleton class into its own ancestors array of
course, right?
Just a little reminder .

Robert

 

[Rick DeNatale]

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

I think that the differences between singleton classes of classes and
regular singleton classes argue for making Array.class respond with
the singleton class of the class, which I'm going to take the liberty
of calling the metaclass to distinguish between metaclasses and
regular singleton classes, which I'll just call singleton classe's in
the following.

1). As you point out unlike regular singleton classes, metaclasses can
have subclasses.

2). Singleton classes are born on demand when they are needed to hold
a singleton method. Metaclasses on the other hand are created at the
time of the birth of their sole instance. In fact I'm almost certain
that if you look at the code flow when a class is created the
metaclass is created first, so in a real sense, the metaclass IS the
birth class of the class.

So I see bringing metaclasses out from behind the curtain, and calling
them metaclasses or something else besides singleton class to
distinguish them from regular singleton classes is useful.

And for those who are fans of access modifiers, I think that this
would allow having protected class methods, since there would be a
visible hierarchy of metaclasses to reason about.

 

[dblack]

Hi --

I think that the differences between singleton classes of classes and
regular singleton classes argue for making Array.class respond with
the singleton class of the class, which I'm going to take the liberty
of calling the metaclass to distinguish between metaclasses and
regular singleton classes, which I'll just call singleton classe's in
the following.

1). As you point out unlike regular singleton classes, metaclasses can
have subclasses.

2). Singleton classes are born on demand when they are needed to hold
a singleton method. Metaclasses on the other hand are created at the
time of the birth of their sole instance. In fact I'm almost certain
that if you look at the code flow when a class is created the
metaclass is created first, so in a real sense, the metaclass IS the
birth class of the class.

I'm thinking of the birth of objects on the Ruby side, though:

c = Class.new

or

class C

where (as far as I can determine) there's no way to get access to the
(thing we're for the moment calling metaclass before the class
itself.

So I see bringing metaclasses out from behind the curtain, and calling
them metaclasses or something else besides singleton class to
distinguish them from regular singleton classes is useful.

And for those who are fans of access modifiers, I think that this
would allow having protected class methods, since there would be a
visible hierarchy of metaclasses to reason about.

I like visibility, and I like non-special-caseness; it's a revelation
to a lot of people to learn, for example, that class methods are
singleton methods on Class objects. On the other hand, as much as I
would like it not to be, it's a special case at some level.

I guess the ideal terminology would encompass both the similarities
and the differences. Clearly there's some very strong identity
between:

class << C # where C is a class

and

class << some_non_class_object

and it makes sense to treat them at least up to a point as the same
thing. (Or *past* a point?) But I don't have the perfect terminology
to hand by any means.


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)

 

[Robert Dober]

I guess the ideal terminology would encompass both the similarities
and the differences. Clearly there's some very strong identity
between:

class << C # where C is a class

and

class << some_non_class_object

and it makes sense to treat them at least up to a point as the same
thing. (Or *past* a point?) But I don't have the perfect terminology
to hand by any means.

Forgive my ignorance, but are they not the same already?

In other words given three arbitrary objects of which one happens to be a class:
o0, o1, o2 = Class.new, String.new, Object.new
s0, s1, s2 = [o0, o1, o2].map{|o| class <<o; self end}

would there be any conceptional differences between s0 and si i>0,
that are not there between s1 and s2?

Or still in other words, and sorry for coming back to the original
topic *again*, is it not outside of the singleton class implementation
that we have to look for unification too?

Now this thread got really quite sophisticated please forgive me if I
have asked a question that has already been answered.

Cheers
Robert

 

[dblack]

Hi --

I guess the ideal terminology would encompass both the similarities
and the differences. Clearly there's some very strong identity
between:

class << C # where C is a class

and

class << some_non_class_object

and it makes sense to treat them at least up to a point as the same
thing. (Or *past* a point?) But I don't have the perfect terminology
to hand by any means.

Forgive my ignorance, but are they not the same already?

In other words given three arbitrary objects of which one happens to be a
class:
o0, o1, o2 = Class.new, String.new, Object.new
s0, s1, s2 = [o0, o1, o2].map{|o| class <<o; self end}

would there be any conceptional differences between s0 and si i>0,
that are not there between s1 and s2?

Or still in other words, and sorry for coming back to the original
topic *again*, is it not outside of the singleton class implementation
that we have to look for unification too?

The thing is, there's one big difference that's not just a matter of
implementation: singleton classes of Class objects are the only ones
that can actually be called by more than one object (the class, plus
its descendants). So that calls into question the appropriateness of
"singleton" as a way of describing them. I'm not a fan of "metaclass"
-- as Jim Weirich (if I recall correctly) said, the only real
metaclass in Ruby, i.e., class of classes, is Class.


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)

 

[Robert Dober]

The thing is, there's one big difference that's not just a matter of
implementation: singleton classes of Class objects are the only ones
that can actually be called by more than one object (the class, plus
its descendants).

I am definitely lost here, what do you mean by "can be called", their
methods of course, ok so that is exactly what I meant, it is the
"outside world" that makes the difference.
It is not the "fault" of the Singleton Class that it does not inherit
from Module, could we imagine the following e.g.:

s="a"
t=class<<s
def hi; 42 end
self
end
c = Class.new{ include t }

BTW I wanted just to be sure that this and some other tricks do not
work and they don't :-(
But Ruby threw a "Virtual Class" to me, actually did we discuss this
name?, I quite like it.

Cheers
Robert

 

[Rick DeNatale]

The thing is, there's one big difference that's not just a matter of
implementation: singleton classes of Class objects are the only ones
that can actually be called by more than one object (the class, plus
its descendants). So that calls into question the appropriateness of
"singleton" as a way of describing them. I'm not a fan of "metaclass"
-- as Jim Weirich (if I recall correctly) said, the only real
metaclass in Ruby, i.e., class of classes, is Class.

And from my viewpoint, that last sentence doesn't seem right, true as
it might be from the current implementation of Object#class. First of
all, if the only real metaclass is Class, then what are those
singleton classes of classes for?

Each one holds the methods for it's sole instance, and for inheritance
by it's sub[class?]es. They are just like classes in that regard.
Hiding the fact that they exist, and giving the illusion that all
Class objects are instances only of Class doesn't seem to be natural
and leads to anomalies like making the concept of protected class
methods empty since the all classes are considered to have the same
class.

And since there really is a distinction between the singleton classes
used for instance behavior, and those sort-of-singleton class thingies
why not have a term which distinguishes them. Metaclass is the common
term for these kinds of objects, and under the covers, ruby singleton
classes of classes look very much like the metaclasses of Smalltalk or
CLOS.

I think it would be interesting to think about what would break if the
following methods were defined/changed.

1) Object#singleton - would return the singleton class of an
instance, creating it if necessary.
2) Module#metaclass - returns the singleton class of the receiver.
3) Object#class - returns the 'birth class' of the object.
Module "overrides" the implementation of this method to return
the metaclass of the receiver.

4) And for Robert D. I don't see the harm in a singleton class
returning itself as the head of the ancestors list.

 

[Robert Dober]

4) And for Robert D. I don't see the harm in a singleton class
returning itself as the head of the ancestors list.

That's what I think too, but there was no feedback whatsoever to my
patch and therefore I settled down to changing the doc, which went
unnoticed too, one could almost say this thread was a disaster, were
it not that it has created a most interesting discussion between David
and yourself

Cheers
Robert

 

[dblack]

Hi --

The thing is, there's one big difference that's not just a matter of
implementation: singleton classes of Class objects are the only ones
that can actually be called by more than one object (the class, plus
its descendants). So that calls into question the appropriateness of
"singleton" as a way of describing them. I'm not a fan of "metaclass"
-- as Jim Weirich (if I recall correctly) said, the only real
metaclass in Ruby, i.e., class of classes, is Class.

And from my viewpoint, that last sentence doesn't seem right, true as
it might be from the current implementation of Object#class. First of
all, if the only real metaclass is Class, then what are those
singleton classes of classes for?

Each one holds the methods for it's sole instance, and for inheritance
by it's sub[class?]es. They are just like classes in that regard.
Hiding the fact that they exist, and giving the illusion that all
Class objects are instances only of Class doesn't seem to be natural
and leads to anomalies like making the concept of protected class
methods empty since the all classes are considered to have the same
class.

And since there really is a distinction between the singleton classes
used for instance behavior, and those sort-of-singleton class thingies
why not have a term which distinguishes them. Metaclass is the common
term for these kinds of objects, and under the covers, ruby singleton
classes of classes look very much like the metaclasses of Smalltalk or
CLOS.

I think it would be interesting to think about what would break if the
following methods were defined/changed.

1) Object#singleton - would return the singleton class of an
instance, creating it if necessary.
2) Module#metaclass - returns the singleton class of the receiver.
3) Object#class - returns the 'birth class' of the object.
Module "overrides" the implementation of this method to return
the metaclass of the receiver.

It still feels to me like this is forking too soon in the road, or
something. I think of the metaclasses as a superset of the singleton
classes -- basically a singleton class, but with something layered on
top (the inheritance thing). So having a different name for them
makes sense to me, but "promoting" them to be the response to #class
doesn't. I fear that this would make:

c = Class.new

very equivocal: one would have to single it out as the one (I think)
case where SomeClass.new did not result in an object which said that
SomeClass was its class.

My counter-proposal would be:

1) Object#birth_class
2) Object#singleton_class
3) Object#class -- alias for #birth_class (for all objects)
4) Class#metaclass -- alias for #singleton_class

It seems to me that would allow full exploitation of the similarities,
and full expression of the differences.

(I know I switched it from Module to Class... still pondering that one



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)

 

[dblack]

Hi --

I am definitely lost here, what do you mean by "can be called", their
methods of course, ok so that is exactly what I meant, it is the
"outside world" that makes the difference.

I meant the inheritance situation:

class C
def C.x
end
end

class D < C
end

D.x # D calling C's "singleton" method (which is therefore
# not really singleton, because more than one object can
# execute it).

It is not the "fault" of the Singleton Class that it does not inherit
from Module, could we imagine the following e.g.:

s="a"
t=class<<s
def hi; 42 end
self
end
c = Class.new{ include t }

BTW I wanted just to be sure that this and some other tricks do not
work and they don't :-(
But Ruby threw a "Virtual Class" to me, actually did we discuss this
name?, I quite like it.

I don't.

(class << ""; self; end).is_a?(Object) # => true

Nothing "virtual" about it


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)

 

[Robert Dober]

Hi --

I meant the inheritance situation:

class C
def C.x
end
end

class D < C
end

D.x # D calling C's "singleton" method (which is therefore
# not really singleton, because more than one object can
# execute it).

I know David, I know, boy I was really expressing myself badly, or
maybe I did not know?
As a matter of fact I am quite confused, I am aware of the correctness
of your statement above but I fail to grasp an important question
about it -- that was why a was thinking about it a lot before posting
again:

Is the fact above a quality of Singleton Classes (seen as an entity of itself)?
or
Is the fact above a quality of how Singleton Classes are used?
or
Are both statements equivalent, no I do not think so.

You see I really get confused about this, I'll just take a break, thx
for spending some time on this.

Cheers
Robert