Error in ancestor?

flatekmonkey · June 21, 2007, 11:03pm

On 6/19/07, [email protected] [email protected] wrote:

On Wed, 20 Jun 2007, Rick DeNatale wrote:

Coming from a background in Smalltalk, my preference would be if this
machinery were more visible and official, but Matz has his reasons for
not doing so. For one thing, not documenting it, and hiding it from
methods like ancestors and class makes it easier to tinker with as the
language evolves without “officially” breaking backward compatibility.

Does that mean that no one who’s ever used Smalltalk can ever think
that it’s right for Ruby to deviate from Smalltalk?

Well David,

In short, NO.

Yesterday I was mulling over three or four topics to write about, your
post
tipped me over, so after a day of thought and editting the longish:

http://talklikeaduck.denhaven2.com/articles/2007/06/21/where-i-come-from

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

flatekmonkey · June 22, 2007, 7:21pm

On 6/21/07, [email protected] [email protected] wrote:

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.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

flatekmonkey · June 22, 2007, 7:26pm

Hi –

On Sat, 23 Jun 2007, Rick DeNatale wrote:

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

flatekmonkey · June 21, 2007, 11:46pm

Hi –

On Fri, 22 Jun 2007, Rick DeNatale wrote:

Does that mean that no one who’s ever used Smalltalk can ever think
that it’s right for Ruby to deviate from Smalltalk?

Well David,

In short, NO.

Yesterday I was mulling over three or four topics to write about, your post
tipped me over, so after a day of thought and editting the longish:

http://talklikeaduck.denhaven2.com/articles/2007/06/21/where-i-come-from

Cool – I’m glad. (BTW there’s an unclosed emphasis tag or something,
causing about the last 1/3 to be in bold.) The points at the end are
especially interesting, about metaprogramming and such in Ruby as
opposed to Smalltalk, and Alan Kay’s comment “that he was disappointed
that so few Smalltalkers experimented with changing and extending
Smalltalk by building off of the mechanisms of Class, Metaclass, and
Behavior.” I’ve actually been, perhaps not disappointed but puzzled,
at the form some of this activity takes – or doesn’t take – in the
Ruby world. In particular, the needle sometimes seems to be stuck in
the groove of certain ways of looking at the matter of changing and/or
amending the behavior of core-class objects. People are definitely
interested, for example, in the idea of having a way to do
block-scoped (or something-scoped) modifications to core classes; but
I think I’ve literally never heard anyone report actually having used
any of the libraries that let one do this. And in my opinion ‘extend’
is massively underutilized; it really could be the answer to almost
every case of wanting to have, say, an Array that can shuffle itself,
or whatever.

As for singleton classes: I still strongly root for
Kernel#singleton_class. I find that people understand the whole thing
quite readily when it’s explained to them that every object has (a) a
“birth” class and (b) a class of its own where it can stash methods
that only it can call. 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.
(Hmmm… therein might lie another essay…

David

flatekmonkey · June 23, 2007, 12:17am

Rick DeNatale wrote:

a cigarette.
Now I know how to pronounce <<: it is the “cigarette” operator!

flatekmonkey · June 22, 2007, 8:58pm

On 6/22/07, [email protected] [email protected] 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.

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.

flatekmonkey · June 23, 2007, 3:46pm

On 6/22/07, Joel VanderWerf [email protected] wrote:

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

Now I know how to pronounce <<: it is the “cigarette” operator!
Oh no, cannot use it anymore at work, forbidden by law
Robert

flatekmonkey · June 23, 2007, 10:15pm

On 6/22/07, Gregory B. [email protected] wrote:

On 6/22/07, [email protected] [email protected] 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.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

flatekmonkey · June 23, 2007, 10:50pm

On 6/23/07, [email protected] [email protected] wrote:

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

flatekmonkey · June 23, 2007, 11:16pm

On 6/23/07, Gregory B. [email protected] wrote:

On 6/23/07, [email protected] [email protected] wrote:

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

flatekmonkey · June 23, 2007, 10:33pm

Hi –

On Sun, 24 Jun 2007, Rick DeNatale wrote:

never had widespread acceptance.
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

flatekmonkey · June 25, 2007, 11:25pm

On 6/23/07, [email protected] [email protected] wrote:

On Sun, 24 Jun 2007, Rick DeNatale wrote:

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…

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.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

flatekmonkey · June 26, 2007, 1:13pm

On 6/25/07, [email protected] [email protected] wrote:

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

flatekmonkey · June 25, 2007, 11:34pm

Hi –

On Tue, 26 Jun 2007, Rick DeNatale wrote:

class" relieved of any responsibility to worry about the singleton.
regular singleton classes, which I’ll just call singleton classe’s in
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

flatekmonkey · June 26, 2007, 1:25pm

Hi –

On Tue, 26 Jun 2007, Robert D. wrote:

class << some_non_class_object

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 W. (if I recall correctly) said, the only real
metaclass in Ruby, i.e., class of classes, is Class.

David

flatekmonkey · June 26, 2007, 5:32pm

On 6/26/07, [email protected] [email protected] wrote:

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

flatekmonkey · June 26, 2007, 9:17pm

On 6/26/07, Rick DeNatale [email protected] wrote:

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

flatekmonkey · June 26, 2007, 9:07pm

On 6/26/07, [email protected] [email protected] wrote:

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

Object#singleton - would return the singleton class of an
instance, creating it if necessary.
Module#metaclass - returns the singleton class of the receiver.
Object#class - returns the ‘birth class’ of the object.
Module “overrides” the implementation of this method to return
the metaclass of the receiver.
And for Robert D. I don’t see the harm in a singleton class
returning itself as the head of the ancestors list.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

flatekmonkey · June 27, 2007, 12:36am

Hi –

On Wed, 27 Jun 2007, Rick DeNatale wrote:

And from my viewpoint, that last sentence doesn’t seem right, true as
class.

Object#singleton - would return the singleton class of an
instance, creating it if necessary.

Module#metaclass - returns the singleton class of the receiver.

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:

Object#birth_class
Object#singleton_class
Object#class – alias for #birth_class (for all objects)
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

flatekmonkey · June 28, 2007, 10:05am

On 6/26/07, [email protected] [email protected] wrote:

Hi –

On Wed, 27 Jun 2007, Robert D. wrote:

On 6/26/07, [email protected] [email protected] wrote:

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