This is the correct title, uh, I think…
dyslexic me 
Ben T. pisze:
This is the correct title, uh, I think…
dyslexic me
The << direction is correct (and intuitive IMHO), given:
class A < B
end
This can do two things, either creates and opens class A extending class
B or reopens class A if it already exits (in the second case the
superclass is optional, but if given it must match the existing class
superclass)
now, given:
s = “some_string”
class << s
end
What this does ? it either creates and opens singleton class for s
instance or reopens the singleton it if it already exits. Since
singleton classes dont have their names you could also imagine
<anonyous_name> between class and << tokens here.
The only question that could arise is: why there are two different
tokens (<< and <) ?. I think Matz wanted to syntactically differentiate
how to deal with classes and metaclasses.
lopex
Marcin Mielżyński wrote:
What this does ? it either creates and opens singleton class for s
instance or reopens the singleton it if it already exits. Since
singleton classes dont have their names you could also imagine
<anonyous_name> between class and << tokens here.
Yes, but there is a major difference between those two. In the former
case A
inherits from B, but in the latter case the singleton class does not
inherit from self, self inherits from the singleton class (well actually
self
is an instance of the singleton class, but the point is that self is
based on
the class and not the other way around), so Ben has a point when he
says,
that the arrows should point in the other direction.
Consider the following excerpt from Programming Ruby (2nd Ed.):
Class Definition
class [ scope:: ] classname [ < superexpr ]
body
end
class << obj
body
end
A Ruby class definition creates or extends an object of class Class by
executing the code in body. In the first form, a named class is created
or extended. The resulting Class object is assigned to a constant named
classname (see below for scoping rules). This name should start with an
uppercase letter. In the second form, an anonymous (singleton) class is
associated with the specific object.
It is only the second form that concerns us. Notice how the author makes
no mention of inheritance, he simply states that “an anonymous
(singleton) class is associated with the specific object.” Indeed, it
would be strange to say instead
something like “an anonymous (singleton) class is derived from the
object” because inheritance is a relation between two classes, not an
object and a class. It seems to me that your inheritance-based
understanding of singleton classes replaces the author’s original words
with this bizarre, alternative explanation.
I say “strange” and “bizarre” rather than “wrong” because the
distinction between classes and objects is somewhat blurred in Ruby, and
especially so in the example I gave previously, where “self” is an
instance of Class. In that context, class << self might be thought of as
a form of dynamic inheritance
because self is a class. The problem with that thought is that it
ignores the
semantics of the construction, which is to add behavior to the value of
the
right-hand operand, “self,” by constructing (or extending) an anonymous
class and adding a reference to that class to the value of “self.” It
does not matter whether the singleton class is constructed or extended
because in each case the
value of “self” does not contribute to the singleton class, it is the
singleton class that contributes to the value of “self.”
But what about: class << object, where object is not a class? As I said
above,
calling this inheritance seems to me to stretch the notion beyond its
proper limits. And, of course, the “semantical” objection I stated in
the previous paragraph applies with at least as much force in this case.
Whether the RHS is
an object or a class, the effect of the operation is to introduce new
functionality via the LHS and add it to the RHS, which is why the arrows
should point toward the RHS.
nbits
Marcin Mielży�?ski wrote:
Ben T. pisze:
This is the correct title, uh, I think…
dyslexic me
The << direction is correct (and intuitive IMHO), given:
class A < B
endThis can do two things, either creates and opens class A extending class
B or reopens class A if it already exits (in the second case the
superclass is optional, but if given it must match the existing class
superclass)now, given:
s = “some_string”
class << s
endWhat this does ? it either creates and opens singleton class for s
instance or reopens the singleton it if it already exits. Since
singleton classes dont have their names you could also imagine
<anonyous_name> between class and << tokens here.The only question that could arise is: why there are two different
tokens (<< and <) ?. I think Matz wanted to syntactically differentiate
how to deal with classes and metaclasses.lopex
Hi –
On Mon, 3 Sep 2007, Ben T. wrote:
term. If the RHS were the same as its class (which is impossible), then
Marcin would be right, because the singleton class would be subclassing
the RHS. But no instance is ever the same as its class. What is really
going on is that we are
augmenting the interface of the RHS by decorating its most derived class
with an anonymous class to which RHS has exclusive access, thus
effectively adding the methods of the singleton class to the RHS. As the
recipient of these new methods, RHS is on the receiving side of the
operation, which is why ‘class >> RHS …’ is more intuitive than ‘class
<< RHS … .’
I’m sorry, but I had to chuckle at the use of the word “intuitive”
after that explanation 
I wouldn’t think of class << obj as having anything at all to do with
inheritance. It’s more like this, in terms of how the class keyword
works:
class expr
where expr can be:
A
A < B
<< arbitrary_object
So the inheritance < is more like:
class (A < B)
and the singleton notation is more like:
class (<< obj)
Remember, also, that the class keyword isn’t itself a class
identifier; you’re not looking for “the class that is >> object”, but
the class that is, so to speak, yielded from object. (Or something.)
It’s not a notation that relates very closely to any other.
David
I like it when people agree with me, and according to the diagram on
page 384 of Programming Ruby, you are basically correct to say that
“self inherits from the singleton class.” The diagram shows that a
“virtual” (singleton) class is inserted into the inheritance hierarchy
for self (or whatever the RHS happens to be) as an immediate subclass of
the most derived, non-singleton, class of which the RHS is an instance
whenever ‘class << RHS …’ is executed. So even if we think of the ‘<<’
as an “inheritance operator,” it is still pointing in the wrong
direction! But is inheritance really the right concept here? Notice that
the singleton class is inserted below the most specific class of the RHS
term. If the RHS were the same as its class (which is impossible), then
Marcin would be right, because the singleton class would be subclassing
the RHS. But no instance is ever the same as its class. What is really
going on is that we are
augmenting the interface of the RHS by decorating its most derived class
with an anonymous class to which RHS has exclusive access, thus
effectively adding the methods of the singleton class to the RHS. As the
recipient of these new methods, RHS is on the receiving side of the
operation, which is why ‘class >> RHS …’ is more intuitive than ‘class
<< RHS … .’
Sebastian H. wrote:
Marcin Mielżyński wrote:
What this does ? it either creates and opens singleton class for s
instance or reopens the singleton it if it already exits. Since
singleton classes dont have their names you could also imagine
<anonyous_name> between class and << tokens here.Yes, but there is a major difference between those two. In the former
case A
inherits from B, but in the latter case the singleton class does not
inherit from self, self inherits from the singleton class (well actually
self
is an instance of the singleton class, but the point is that self is
based on
the class and not the other way around), so Ben has a point when he
says,
that the arrows should point in the other direction.
unknown wrote:
Hi –
Perhaps you were misled by the first sentence of my reply to Sebastian,
in which
I said ‘you are basically correct to say that “self inherits from the
singleton class.”.’ Note the “basically” qualification. Apart from that
sentence, my entire exposition prior to this reply, which spans two
postings, argues against the idea that “<<” signifies inheritance in:
class << object
…
end
In pseudocode, this translates into:
object.method1 # error
object.method2 # error
- temp = Class.new { method1, method2, … }
- temp.superclass = object.class
- object.class = temp
object.method1 # OK
object.method2 # OK
Thus 1-3 might be more succinctly expressed as:
Class.new { method1, method2 } >> object
which is very close to:
class >> object # instead of class << object
def method1
…
end
def method2
…
end
end
Got it?
nbits
I’m sorry, but I had to chuckle at the use of the word “intuitive”
after that explanationI wouldn’t think of class << obj as having anything at all to do with
inheritance. It’s more like this, in terms of how the class keyword
works:class expr
where expr can be:
A
A < B
<< arbitrary_objectSo the inheritance < is more like:
class (A < B)
and the singleton notation is more like:
class (<< obj)
Remember, also, that the class keyword isn’t itself a class
identifier; you’re not looking for “the class that is >> object”, but
the class that is, so to speak, yielded from object. (Or something.)
It’s not a notation that relates very closely to any other.David