[ANN] Article: Seeing Metaclasses Clearly
why the lucky stiff
classes or metaobjects), since they still lurk under a shroud of fear
and enigma.
<http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html>
I'm hoping this will help uncover the truth. If anything is unclear,
please report it. Shed a light.
Sharkin',
_why
Sascha Ebach
Very nice and thanks,
would you mind using a print stylesheet so the article can be nicely
printed out?
Sascha Ebach
David A. Black
For some reason the first 1/8 inch or so on the left are cut off on my
browser. I don't know whether it's a CSS thing or a browser thing
(Netscape 6). So "methods" comes out as "thods", etc.
The tutorial itself looks good, though the terminology in this area
continues to be a problem. My understanding is that the most general
term is "singleton class", and that "metaclass" is a special term for
singleton class of a Class object. (See Pickaxe, 2nd ed., p. 382.)
So, for example, I would rename your Object#metaclass method
#singleton_class, since it applies to all objects (as per RCR 231).
Then there's "virtual class", which I think is the weakest and least
useful term, certainly at a general level. The Matz paraphrase on
p.382 suggests that virtual-ness is more a matter of implementation
than anything language-level, which is good. I haven't checked, but
I'm hoping the > 1.8 error messages will cease to refer to "virtual"
classes (e.g., when you try to get at the singleton class of a
Fixnum).
David
--
David A. Black
dbl...@wobblini.net
Florian Groß
> <http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html>
>
> I'm hoping this will help uncover the truth. If anything is unclear,
> please report it. Shed a light.
Nice article, but I disagree in the point that @@vars are simpler than
class instance variables. Class instance variables have odd semantics in
the current Ruby which means that they will probably do some detail
different than you expect.
I've found that sticking to class instance variables (and thus keeping
things simple -- why do we need another type of variables again?) helps
in making code easier to understand.
Perhaps you should display both sides of this in the article.
Gavin Kistner
> Nice article, but I disagree in the point that @@vars are simpler than
> class instance variables. Class instance variables have odd semantics
> in the current Ruby which means that they will probably do some detail
> different than you expect.
But you have to do:
class Foo
@var1 = []
@var2 = {}
class << self
attr_accessor :var1, :var2
end
end
to get reasonable access to those class instance variables inside an
instance method, and even then you have to do self.class.var1
Once you 'get it' it's not TERRIBLY difficult, but I would say that the
above is more than enough justification for calling @@foo simpler.
Simpler, but also confusing in the inherited-class cases. (So confusing
that I still don't fully grok what specifically occurs that makes @@foo
unusable, and when it occurs. I'm still grasping at the fringes of the
tablecloth.)
Karl von Laudermann
Noticed a small mistake; At one point, you refer to the at-sign (@) as
an ampersand. Other than that... the article went way over my head and
twisted my poor brain into knots. :-( I think I'll need to re-read
chapter 24 of Pickaxe 2 immediately before reading this article.
why the lucky stiff
> Nice article, but I disagree in the point that @@vars are simpler than
> class instance variables. Class instance variables have odd semantics in
> the current Ruby which means that they will probably do some detail
> different than you expect.
You're right. I'm oversimplifying this. I need to discuss the
metaclass/inheritance thing a bit more.
_why
Curt Hibbs
> Hi --
>
> On Mon, 18 Apr 2005, why the lucky stiff wrote:
>
>> I've written a very nuts+bolts article on metaclasses (aka virtual
>> classes or
>> metaobjects), since they still lurk under a shroud of fear and enigma.
>>
>> <http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html>
>>
>> I'm hoping this will help uncover the truth. If anything is unclear,
>> please
>> report it. Shed a light.
>
>
> For some reason the first 1/8 inch or so on the left are cut off on my
> browser. I don't know whether it's a CSS thing or a browser thing
> (Netscape 6). So "methods" comes out as "thods", etc.
Also, in Firefox 1.0 on Windows XP, when I try to print it, it only
prints the first page. If I use MS Internet Explorer, it prints just fine.
Curt
why the lucky stiff
> The tutorial itself looks good, though the terminology in this area
> continues to be a problem. My understanding is that the most general
> term is "singleton class", and that "metaclass" is a special term for
> singleton class of a Class object. (See Pickaxe, 2nd ed., p. 382.)
> So, for example, I would rename your Object#metaclass method
> #singleton_class, since it applies to all objects (as per RCR 231).
Sure, I'm aware that "virtual class" is the generic term, while Matz has
also used "singleton class" and "meta-object" to describe these classes
used in tandem with an RObject.
I only use the term "metaclass" because it is the term predominantly
used in the PickAxe II. While Dave does interchangibly use "virtual
class" and "singleton class", the only term he uses to generically refer
to the construct is "metaclass".
And I really need to be able to wrap these up in a single word, whilst
still jiving with the PickAxe.
_why
Mike Woodhouse
Glad I'm not the only one who has to go back to the books! (I did spot
the "ampersand" thing, though).
mark sparshatt
One thing I found confusing was the comment for the class_def method
># Just defines a class method
>def class_def name, &blk
> class_eval { define_method name, &blk }
>end
However it actually defines an instance method
require "metaid"
class MyClass
class_def "class_method" do puts "success" end
end
MyClass.class_method
#=> undefined method "class_method" for MyClass:Class
MyClass.new.class_method #=> success
--
Mark Sparshatt
Robert Klemme
"Florian Groß" <flo...@gmail.com> schrieb im Newsbeitrag
news:d4093s$dml$1...@sea.gmane.org...
+1
> Perhaps you should display both sides of this in the article.
Yeah, I missed that, too. In fact, the article seems to discourage class
instance variable usage...
Kind regards
robert
Jeffrey Moss
Nice tutorial, I found I learned something from it. I know there is a
chapter in the pickaxe that attempts to explain this, but this seems to be
the best (only?) freely available explanation.
Being somewhat new to the concept of metaprogramming, I can tell you what is
particularly confusing is the use of class << self, how this is like the
root of all singleton behavior, how it differs from class a < b (perhaps
even display how it works inside the interpreter). I wasn't sure what the
difference between the < and the << operator was, so I had to go look it up.
Also the difference between class instance variables and class variables
could use some extra explaining, it seems you're just saying what to do and
what not to do, but not why you can't or shouldn't do it, and why a @@ class
variable is handy.
Thanks,
-Jeff
Jeffrey Moss
firefox bug.
-Jeff
Lionel Thiry
The only I've found to make your sample code work is to refactor class_def this way:
def class_def name, &blk
meta_eval { define_method name, &blk }
end
I personnaly feel it weird I could not realise this whithout the help of the
metaclass manipulation methods _why has added.
--
Lionel Thiry
Lionel Thiry
Errata
In the begining of the page:
"I’ve been keeping these methods in a file called metaid.rb and it’s a start
toward building a little library that can simplify use of metaclasses. Let’s
talk about metaclasses and I advise you to keep metaid.rb at your side. Let’s
talk about metaclasses and I advise you to keep metaid.rb at your side."
"Let’s talk about metaclasses and I advise you to keep metaid.rb at your side."
is said twice.
--
Lionel Thiry
Personal website: http://users.skynet.be/lthiry/
why the lucky stiff
> Being somewhat new to the concept of metaprogramming, I can tell you
> what is particularly confusing is the use of class << self, how this
> is like the root of all singleton behavior, how it differs from class
> a < b (perhaps even display how it works inside the interpreter). I
> wasn't sure what the difference between the < and the << operator was,
> so I had to go look it up.
My article briefly discusses the singleton class notation (the << you
are referring to). This notation is very simple to understand once
you've gotten the hang of:
1. Objects are containers for instance variables.
2. Classes are containers for methods and instance variables.
There are more to objects and classes than this, but for the sake of
this discussion, it's useful to whittle it down to this.
a = Object.new
a.instance_variable_set( "@name", "Jeff" )
I've created a new object above, storage for instance variables. I've
added an instance variable to the object. In doing so, I called the
`instance_variable_set' method. This method isn't contained in the `a'
object. It's contained way up the inheritance tree, in the Object class.
Again: the instance variables are stored in the object. The methods are
stored in a class up the inheritance tree.
class << a
def name; @name; end
end
We're opening a metaclass here. What is a metaclass? It's method
storage for an object. An object can only store instance variables.
The `name' method has been added to the metaclass (the personal method
storage) for the object `a'.
The most needlessly confusing construct in Ruby is `class << self'.
You're simply accessing the method storage for whatever object is
currently `self'.
class Dragon
class << self; p self; end
end
Prints: #<Class:Dragon>
Okay, so we're in the metaclass for a class. But what is that?
It's method storage for class methods. Normal instance methods are
stored directly in the class. But class methods are stored in the
metaclass.
class Dragon
def self.me; p self; end # This method is stored in the metaclass
def me; p self; end # This method is stored in the class
end
Dragon.me #=> Dragon
Dragon.new.me #=> #<Dragon:0x80914e0>
Everyone who uses class methods uses metaclasses.
class << Dragon
def roar; "#<CLASS:ROAR>"; end
end
Dragon.roar #=> #<CLASS:ROAR>
d = Dragon.new
class << d
def roar; "#<OBJ:ROAR>"; end
end
d.roar #=> #<OBJ:ROAR>
I don't really get into this in the article, since I've opted to use the
`metaclass' method and `meta_eval' which are alternate forms of the above.
The < operator is a completely different operator, used strictly for
setting the superclass of a class.
But one handy thing about metaclass (which I believe qualifies them for
the meta- prefix) is that they follow the inheritance tree, simply
remaining one level removed.
>> Dragon.metaclass
=> #<Class:Dragon>
>> Dragon.metaclass.superclass
=> #<Class:Object>
>> Dragon.superclass.metaclass
=> #<Class:Object>
See, an object's metaclass' superclass is the same as the object's
superclass' metaclass.
> Also the difference between class instance variables and class
> variables could use some extra explaining, it seems you're just saying
> what to do and what not to do, but not why you can't or shouldn't do
> it, and why a @@ class variable is handy.
I'll address this once I'm sure I completely understand variable.c and
have played around with class variables in metaclasses a bit more.
_why
why the lucky stiff
> The only I've found to make your sample code work is to refactor
> class_def this way:
> def class_def name, &blk
> meta_eval { define_method name, &blk }
> end
That's the `meta_def' you've recreated above.
The `class_def' method is intended to be used to add instance methods
(like the `initialize' I'm adding in Dwemthy's Array):
class Dragon; end
Dragon.class_def :initialize do
@life = 11; @strength = 12
end
>> d = Dragon.new
=> #<Dragon:0xb7d571e8 @strength=12, @life=11>
The `meta_def' can be used to add class methods, because of reasons
stated throughout the article and in my response to Jeff.
_why
Florian Groß
> The `class_def' method is intended to be used to add instance methods
> (like the `initialize' I'm adding in Dwemthy's Array):
>
> class Dragon; end
> Dragon.class_def :initialize do
> @life = 11; @strength = 12
> end
Oh, that's already done by Module#define_method then. Perhaps you can
just make that method public?
Lyndon Samson
"It's an important lesson: objects do not store methods, only classes can."
Might be nice to contrast this with prototype based languages like javascript.
Or ProtoRuby ;-)
class ProtoObj
def initialize
@methods = {}
end
def addMethod(name, &method)
@methods[name.id2name] = method
end
def method_missing(method, *args)
@methods[method.id2name].call(*args)
end
end
dog = ProtoObj.new
dog.addMethod(:bark) {
puts "Bark"
}
dog.bark
David A. Black
On Mon, 18 Apr 2005, why the lucky stiff wrote:
I read the Pickaxe differently, especially the box on p. 382. It
paraphrases Matz as having said: "You can call it _metaclass_ but,
unlike Smalltalk, it's not a class of a class; it's a singleton class
of a class."
I don't think there's any case where Dave refers to a singleton class
as a metaclass, except where the object is a Class, but I could be
wrong about that... ?
Anyway, when RCR 231 gets addressed, we'll find out for sure :-)
(I think I misread the p. 382 thing about "virtual". It does actually
sound like Matz is accepting it as a synonym for "singleton", though I
avoid it because I don't see anything "virtual" about singleton
classes. They're objects.)
David A. Black
while the remaining parts are likely unreadable without MIME-aware tools.
Lionel Thiry
def class_def name, &blk
class_eval { self.define_method name, &blk }
end
It was the other solution I thought for.
Jim Weirich
> On Mon, 18 Apr 2005, why the lucky stiff wrote:
> > I only use the term "metaclass" because it is the term predominantly used
> > in the PickAxe II. While Dave does interchangibly use "virtual class"
> > and "singleton class", the only term he uses to generically refer to the
> > construct is "metaclass".
On Monday 18 April 2005 03:55 pm, David A. Black wrote:
> I read the Pickaxe differently, especially the box on p. 382. It
> paraphrases Matz as having said: "You can call it _metaclass_ but,
> unlike Smalltalk, it's not a class of a class; it's a singleton class
> of a class."
I don't have the pickaxe with me (its at work), but let me quote from "Putting
Metaclasses to Work" by Ira R. Forman and Scott H. Danforth. The quote is
longish, but useful in understanding metaclasses. From the Preface:
> "If one thinks of objects as cookies, then classes are analogous to cookie
> cutters. Cookie cutters are teamplates that are used to make and determine
> the properties of cookies; classes make and determine the properties of
> objects. But ow are cookie cutters themselvfes made? Let us ssay that they
> are pressed from sheet metal using a cookie cutter press (a piece of heavy
> machinery). So, if a cookie cutter press is ed to make cookie cutters, what
> is used to make classes? The answer is a metaclass."
So, the instances of a metaclass are classes. Ruby happens to implement
metaclasses as singleton classes (or virtual classes, whatever). So the
singleton class of a class is a metaclass, but the singleton class of
something that is not a class, would not be a meta class.
I would modify Why's metaid library thusly:
class Object
def singletonclass
class << self
self
end
end
end
class Class
def metaclass
singletonclass
end
end
Allowing ...
>> o = Object.new
=> #<Object:0x40253228>
>> Object.metaclass
=> #<Class:Object>
>> o.metaclass
NoMethodError: undefined method `metaclass' for #<Object:0x40253228>
from (irb):4
>> o.singletonclass
=> #<Class:#<Object:0x40253228>>
>> Object.metaclass == Object.singletonclass
=> true
> (I think I misread the p. 382 thing about "virtual". It does actually
> sound like Matz is accepting it as a synonym for "singleton", though I
> avoid it because I don't see anything "virtual" about singleton
> classes. They're objects.)
I think the "virtual" is a modifier of "class", not "object". A virtual class
is something that is like a class in someways (it holds instance methods),
but unlike a class in other ways (can't create new instances of it).
--
-- Jim Weirich j...@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Martin DeMello
>
> So, the instances of a metaclass are classes. Ruby happens to implement
> metaclasses as singleton classes (or virtual classes, whatever). So the
> singleton class of a class is a metaclass, but the singleton class of
> something that is not a class, would not be a meta class.
>
> I would modify Why's metaid library thusly:
>
> class Object
> def singletonclass
> class << self
> self
> end
> end
> end
> class Class
> def metaclass
> singletonclass
> end
> end
+1 - in fact, I think that should go into the FAQ, under "What is the
difference between a singleton class and a metaclass?"
martin
ts
J> So, the instances of a metaclass are classes. Ruby happens to implement
J> metaclasses as singleton classes (or virtual classes, whatever). So the
J> singleton class of a class is a metaclass, but the singleton class of
J> something that is not a class, would not be a meta class.
A singleton class never create an instance, in ruby.
Don't make confusion with another language, which use
"Putting Metaclasses to Work: A New Dimension in Object-Oriented
Programming"
as references.
Guy Decoux
David A. Black
On Tue, 19 Apr 2005, Jim Weirich wrote:
> I wrote:
>>
>> (I think I misread the p. 382 thing about "virtual". It does actually
>> sound like Matz is accepting it as a synonym for "singleton", though I
>> avoid it because I don't see anything "virtual" about singleton
>> classes. They're objects.)
>
> I think the "virtual" is a modifier of "class", not "object". A virtual class
> is something that is like a class in someways (it holds instance methods),
> but unlike a class in other ways (can't create new instances of it).
It is a modifier of "class", not "object"; I think Matz (via Pickaxe)
is saying that "virtual class" is an acceptable synonym for "singleton
class". Actually I don't like it both for my reason ("virtual", taken
on its own, doesn't evoke something as concrete as a singleton class)
and for your reason (it has a meaning in other languages that is only
a partial fit, as I understand it, for Ruby's singleton classes).
David A. Black
On Tue, 19 Apr 2005, Jim Weirich wrote:
> I would modify Why's metaid library thusly:
>
> class Object
> def singletonclass
Aww, don't you like the _ in my RCR? :-) (singleton_class)
David A. Black
On Tue, 19 Apr 2005, Jim Weirich wrote:
> I don't have the pickaxe with me (its at work), but let me quote from "Putting
> Metaclasses to Work" by Ira R. Forman and Scott H. Danforth. The quote is
> longish, but useful in understanding metaclasses. From the Preface:
>
>> "If one thinks of objects as cookies, then classes are analogous to cookie
>> cutters. Cookie cutters are teamplates that are used to make and determine
>> the properties of cookies; classes make and determine the properties of
>> objects. But ow are cookie cutters themselvfes made? Let us ssay that they
>> are pressed from sheet metal using a cookie cutter press (a piece of heavy
>> machinery). So, if a cookie cutter press is ed to make cookie cutters, what
>> is used to make classes? The answer is a metaclass."
>
> So, the instances of a metaclass are classes. Ruby happens to implement
> metaclasses as singleton classes (or virtual classes, whatever). So the
> singleton class of a class is a metaclass, but the singleton class of
> something that is not a class, would not be a meta class.
I have some trouble applying the quotation to Ruby, since classes make
but don't determine the properties of objects, and also -- even more
-- because that description of a metaclass sounds more like class
Class than like singleton classes of classes (since class Class is the
only thing in Ruby from which arbitrarily many Class objects can be
"pressed"). So it doesn't really seem like singleton classes of
classes are accounted for in the quotation.
(I will try to consolidate my comments next time and not respond three
times in a row :-)
Jim Weirich
David A. Black said:
> I have some trouble applying the quotation to Ruby, since classes make
> but don't determine the properties of objects,
I think you misunderstand "properties". It is true that the class does
not (directly) influence the attributes/instance variables of an object.
But properties also include the methods of the object, which are directly
influenced by the class.
Actually, the objections regarding "making objects" and "instance variable
properties" goes more to saying that the singleton classes of classes are
not /classes/, rather than saying they are not /meta/.
What I was trying to focus on is the tendency for folks to call /any/
singleton class a metaclass. I was just arguing that not all singleton
classes are metaclasses. I guess we can continue to discuss whether some
subset of singleton classes might be metaclasses.
> Aww, don't you like the _ in my RCR? :-) (singleton_class)
I should have refered to the RCR before responding. I added my vote in
favor of it!
David A. Black
On Wed, 20 Apr 2005, Jim Weirich wrote:
>
> David A. Black said:
>> I have some trouble applying the quotation to Ruby, since classes make
>> but don't determine the properties of objects,
>
> I think you misunderstand "properties". It is true that the class does
> not (directly) influence the attributes/instance variables of an object.
> But properties also include the methods of the object, which are directly
> influenced by the class.
I was actually thinking of methods, mainly. And you've swapped in a
new wording :-) I'd go along with "directly influenced", but not
"determined"; that is, an object's "birth class" certainly has a role
to play in the object's method capabilities, but is not a determinant.
> Actually, the objections regarding "making objects" and "instance variable
> properties" goes more to saying that the singleton classes of classes are
> not /classes/, rather than saying they are not /meta/.
I must have garbled something I said somewhere along the line; I
definitely would never (knowingly :-) suggest that singleton classes
are not classes. See below....
> What I was trying to focus on is the tendency for folks to call /any/
> singleton class a metaclass. I was just arguing that not all singleton
> classes are metaclasses. I guess we can continue to discuss whether some
> subset of singleton classes might be metaclasses.
What I got from the quotation, and your gloss on it, was that
"metaclass" is recognized (outside of Ruby) to mean a factory for
classes, and that therefore it could be used to refer to a Class
object's singleton class. I would argue the opposite: singleton
classes, in every case, are non-factories, so to the extent that
"metaclass" might suggest factory-ness (i.e., factory of Class
objects), it could be misleading -- not only as a general term for
"singleton class" (which we both agree it isn't), but even as a
specialized term for "singleton class of Class object".
Correspondingly, if there is a "template for making cookie cutters
themselves" (to paraphrase) in Ruby, it would be the object Class
itself. So Class could be called *the* metaclass :-)
Jim Weirich
David A. Black said:
> I'd go along with "directly influenced", but not
> "determined"; that is, an object's "birth class" certainly has a role
> to play in the object's method capabilities, but is not a determinant.
As do all the ancestors in the
> What I got from the quotation, and your gloss on it, was that
> "metaclass" is recognized (outside of Ruby) to mean a factory for
> classes, and that therefore it could be used to refer to a Class
> object's singleton class.
The analogy in the quote did indeed focus on the creation aspect, and I
did indeed gloss over the fact that singleton classes don't create new
instances. Perhaps the analogy was poorly suited for my point.
What I was trying to communicate with the quote is that Metaclasses are to
classes what classes are to objects. As classes hold the behavior for
objects, metaclasses hold the behavior classes. A Metaclass is a class
whose instances are classes (or in the case of a singleton metaclass, whos
one and only instance is a class).
> I must have garbled something I said somewhere along the line; I
> definitely would never (knowingly :-) suggest that singleton classes
> are not classes. See below....
And just as the inability to create new instances does not disqualify
singleton classes from being classes, the inability for a singleton
metaclass does not disqualify it from being a metaclass.
> Correspondingly, if there is a "template for making cookie cutters
> themselves" (to paraphrase) in Ruby, it would be the object Class
> itself.
Indeed, Class is the Metaclass from which all the singleton metaclasses
derive.
Jim Weirich
Jim Weirich said:
> As do all the ancestors in the
Sorry, a half formed thought escaped through my fingers. Just ignore this
part.
David A. Black
On Wed, 20 Apr 2005, Jim Weirich wrote:
>
> David A. Black said:
>> I'd go along with "directly influenced", but not
>> "determined"; that is, an object's "birth class" certainly has a role
>> to play in the object's method capabilities, but is not a determinant.
>
> As do all the ancestors in the
>
>> What I got from the quotation, and your gloss on it, was that
>> "metaclass" is recognized (outside of Ruby) to mean a factory for
>> classes, and that therefore it could be used to refer to a Class
>> object's singleton class.
>
> The analogy in the quote did indeed focus on the creation aspect, and I
> did indeed gloss over the fact that singleton classes don't create new
> instances. Perhaps the analogy was poorly suited for my point.
>
> What I was trying to communicate with the quote is that Metaclasses are to
> classes what classes are to objects. As classes hold the behavior for
> objects, metaclasses hold the behavior classes. A Metaclass is a class
> whose instances are classes (or in the case of a singleton metaclass, whos
> one and only instance is a class).
Although... here's something interesting:
irb(main):001:0> a = ""
=> ""
irb(main):002:0> c = (class << a; self; end)
=> #<Class:#<String:0x401f8b6c>>
irb(main):003:0> a.instance_of?(c)
=> false
irb(main):004:0> a.instance_of?(String)
=> true
irb(main):005:0> s = class << String; self; end
=> #<Class:String>
irb(main):006:0> String.instance_of?(s)
=> false
irb(main):007:0> String.instance_of?(Class)
=> true
I guess being an instance_of something is a unique relationship (only
one class-of-which-you-are-an-instance to a customer), and having a
singleton class doesn't mean you're an instance of it. That seems to
reinforce the non-factory aspect of all singleton classes, in the
sense that it disallows even the one "instance of" relationship that
one might have expected them to claim to have. (I expected it -- I
think I once knew, but had forgotten about, the above behavior.)
>> I must have garbled something I said somewhere along the line; I
>> definitely would never (knowingly :-) suggest that singleton classes
>> are not classes. See below....
>
> And just as the inability to create new instances does not disqualify
> singleton classes from being classes, the inability for a singleton
> metaclass does not disqualify it from being a metaclass.
OK... but that, again, is where the quotation then becomes confusing,
since its chief point is that a "metaclass" is, specifically, a
factory for classes. If we use the word "metaclass" to mean singleton
class of a class, we're definitely giving up any "cookie-cutter"
analogy, and that seemed to be the whole thrust of that quotation.
>> Correspondingly, if there is a "template for making cookie cutters
>> themselves" (to paraphrase) in Ruby, it would be the object Class
>> itself.
>
> Indeed, Class is the Metaclass from which all the singleton metaclasses
> derive.
And all other Class objects too. But then "[Mm]etaclass" becomes
really kind of overloaded -- in the sense that on the one hand it is a
suitable term for Class (which is truly the thing that stamps out the
cookie cutters themselves), while on the other hand it gets used as a
term for something which is unequivocally *not* in the cookie-cutter,
meta-cookie-cutter, or factory family at all.
Jim Weirich
> Although... here's something interesting:
>
instances ...]
Wow ... I didn't see that coming. That has implications for elsewhere in the
thread discussing the Ruby object model diagram where everyone is drawing
ASCII art with arrows labeled "instance-of". All those diagrams are rendered
invalid in one fell swoop. Wow. (I notice that Matz's diagram in the RI docs
does not explicitly label the horizontal arrows "instance-of" ).
So, what do we call the relationship between a class and its singleton class?
"singleton-instance-of"? Maybe.
Given that the Forman/Danforth formal definition of a metaclass is "A
metaclass is an object whose instances are classes", then the only
Forman/Danforth metaclass in Ruby is the class Class.
Although, after rereading the first few chapters of the book, it is clear that
the Class singleton classes fulfill a very similar role to the classical
Forman/Danforth metaclasses. One could argue that Forman's use of
"instance-of" really maps to "singleton-instance-of" ... but at that point we
are arguing definitions and it not worth pursuing.
> I guess being an instance_of something is a unique relationship (only
> one class-of-which-you-are-an-instance to a customer), and having a
> singleton class doesn't mean you're an instance of it. That seems to
> reinforce the non-factory aspect of all singleton classes, in the
> sense that it disallows even the one "instance of" relationship that
> one might have expected them to claim to have. (I expected it -- I
> think I once knew, but had forgotten about, the above behavior.)
It also makes the name "Singleton" class a little odd. I thought it was
because a singleton class could only have a single instance. Now I find out
it can't even have that. Perhaps they should be Zeroton classes :)
> > Indeed, Class is the Metaclass from which all the singleton metaclasses
> > derive.
>
> And all other Class objects too.
Only things (that would be called metaclasses if they could only have
instances) are derived (i.e. inherit) from Class. All other class objects
are merely instances of Class.
> But then "[Mm]etaclass" becomes
> really kind of overloaded -- in the sense that on the one hand it is a
> suitable term for Class (which is truly the thing that stamps out the
> cookie cutters themselves), while on the other hand it gets used as a
> term for something which is unequivocally *not* in the cookie-cutter,
> meta-cookie-cutter, or factory family at all.
The formal definition does not require metaclasses (or classes) to create
instances ... only that they /have/ instances (which is you so clearly
demonstrated singleton classes have no instances). The factory aspect was
entirely part of the analogy and not part of the formal definition.
Pit Capitain
>
> Although... here's something interesting:
>
> irb(main):001:0> a = ""
> => ""
> irb(main):002:0> c = (class << a; self; end)
> => #<Class:#<String:0x401f8b6c>>
> irb(main):003:0> a.instance_of?(c)
> => false
> irb(main):004:0> a.instance_of?(String)
> => true
> irb(main):005:0> s = class << String; self; end
> => #<Class:String>
> irb(main):006:0> String.instance_of?(s)
> => false
> irb(main):007:0> String.instance_of?(Class)
> => true
But note that
irb(main):001:0> a = ""
=> ""
irb(main):002:0> c = (class << a; self; end)
=> #<Class:#<String:0x2dae6d0>>
irb(main):003:0> c === a
=> true
Regards,
Pit
David A. Black
On Wed, 20 Apr 2005, Jim Weirich wrote:
> It also makes the name "Singleton" class a little odd. I thought it was
> because a singleton class could only have a single instance. Now I find out
> it can't even have that. Perhaps they should be Zeroton classes :)
I always thought it was singleton in the sense that, unlike the "birth
class", it was not shared with other objects. There is of course a
long history of discussion about the term "singleton", and the fact
that it's overloaded.... I've suggested "own class", and others have
suggested other terms, though I don't know that even a pronouncement
from Matz will change usage completely.
>>> Indeed, Class is the Metaclass from which all the singleton metaclasses
>>> derive.
>>
>> And all other Class objects too.
>
> Only things (that would be called metaclasses if they could only have
> instances) are derived (i.e. inherit) from Class. All other class objects
> are merely instances of Class.
But being a (mere) instance of Class is, I think, by far the closest
thing in Ruby to matching the proto-cookie-cutter thing. (I know
that's just an analogy, but Class actually fits it rather well.) Not
that every instance of Class is a metaclass, but rather that Class is
a metaclass, on account of the fact that it can create new classes
(meta or otherwise).
>> But then "[Mm]etaclass" becomes
>> really kind of overloaded -- in the sense that on the one hand it is a
>> suitable term for Class (which is truly the thing that stamps out the
>> cookie cutters themselves), while on the other hand it gets used as a
>> term for something which is unequivocally *not* in the cookie-cutter,
>> meta-cookie-cutter, or factory family at all.
>
> The formal definition does not require metaclasses (or classes) to create
> instances ... only that they /have/ instances (which is you so clearly
> demonstrated singleton classes have no instances). The factory aspect was
> entirely part of the analogy and not part of the formal definition.
Like "singleton", though, this may be a case where Matz isn't using it
in a way that fits precisely with any previous formal definitions. I
guess that's one of the hazards of writing a language with a cool,
uncommon design :-)
David A. Black
On Wed, 20 Apr 2005, Pit Capitain wrote:
> David A. Black schrieb:
>>
>> irb(main):001:0> a = ""
>> => ""
>> irb(main):002:0> c = (class << a; self; end)
>> => #<Class:#<String:0x401f8b6c>>
>> irb(main):003:0> a.instance_of?(c)
>> => false
>> irb(main):004:0> a.instance_of?(String)
>> => true
>> irb(main):005:0> s = class << String; self; end
>> => #<Class:String>
>> irb(main):006:0> String.instance_of?(s)
>> => false
>> irb(main):007:0> String.instance_of?(Class)
>> => true
>
> But note that
>
> irb(main):001:0> a = ""
> => ""
> irb(main):002:0> c = (class << a; self; end)
> => #<Class:#<String:0x2dae6d0>>
> irb(main):003:0> c === a
> => true
Yes, a.kind_of(c) is true, but that's never been a one-only
relationship.
Carlos
> On Tuesday 19 April 2005 09:29 pm, David A. Black wrote:
> > Although... here's something interesting:
> >
> [... elided IRB session that illustrates that singleton classes have no
> instances ...]
>
> Wow ... I didn't see that coming. That has implications for elsewhere in the
> thread discussing the Ruby object model diagram where everyone is drawing
> ASCII art with arrows labeled "instance-of". All those diagrams are rendered
> invalid in one fell swoop. Wow. (I notice that Matz's diagram in the RI docs
> does not explicitly label the horizontal arrows "instance-of" ).
Wow, it was only me. Since when I am everyone? Thanks for the compliment,
anyway.
Before your discoveries make you jump into conclusions, you should apply a
little of scientific thought. You have two facts: one, that the diagram
shows that Object --instanceof--> (Object). The other: that
$ ruby -e 'p Object.instance_of?(class<<Object;self;end)'
false
One possible explanation for this discrepancy is that the diagram is wrong.
Another is that instance_of? doesn't take into account singleton classes.
I guess it's the second one :).
Good luck.
David A. Black
On Wed, 20 Apr 2005, Carlos wrote:
> Before your discoveries make you jump into conclusions, you should apply a
> little of scientific thought. You have two facts: one, that the diagram
> shows that Object --instanceof--> (Object). The other: that
>
> $ ruby -e 'p Object.instance_of?(class<<Object;self;end)'
> false
>
> One possible explanation for this discrepancy is that the diagram is wrong.
> Another is that instance_of? doesn't take into account singleton classes.
>
> I guess it's the second one :).
instance_of? tells you (accurately, definitively) whether or not
something is an instance of something. Obviously you can draw a
diagram that posits any relationship you wish. I could write a
diagram that shows Array to be the superclass of String, for example,
and claim that #superclass "doesn't take into account" the fact that
Array is the superclass of String. But if the diagram isn't actually
diagramming Ruby's view of things, then it won't have much value.
ts
C> Before your discoveries make you jump into conclusions, you should apply a
C> little of scientific thought. You have two facts: one, that the diagram
C> shows that Object --instanceof--> (Object). The other: that
More I follow this discussion, more I've problem.
Where do you see (except in a book which don't describe the ruby object
model) that the diagram show
"Object --instanceof--> (Object)"
It's clearly stated
Classes in Ruby are first-class objects---each is an instance of
class +Class+.
and it don't exist an horizontal arrow for this case.
Guy Decoux
Carlos
Noo... I didn't see that anywhere, I wrote this in my diagram. Is it wrong?
I saw that rb_obj_is_instance_of does:
if (rb_obj_class(obj) == c) return Qtrue;
and rb_obj_class does:
return rb_class_real(CLASS_OF(obj));
and rb_class_real does:
while (FL_TEST(cl, FL_SINGLETON) || TYPE(cl) == T_ICLASS) {
cl = RCLASS(cl)->super;
}
So I thought it was skipping the singleton classes. Or isn't it?
search_method, on the other hand, doesn't skip anything.
From the above I deduced the diagram. In which step should I have applied a
little more scientific thinking? :) Where does ruby search for methods, if
not in the inheritance chain?
Chris Pine
> > Another is that instance_of? doesn't take into account singleton classes.
> >
> > I guess it's the second one :).
>
> instance_of? tells you (accurately, definitively) whether or not
> something is an instance of something. Obviously you can draw a
> diagram that posits any relationship you wish.
Then what do the sideways arrows in the 'ri Class' documentation mean?
Carlos didn't draw that diagram, and he isn't making that up.
Clearly, there's a meaningful relationship there.
See again the 'klass' arrow on page 384 (Figure 24.3) of the Pickaxe2.
If "instance_of? tells you (accurately, definitively) whether or not
something is an instance of something", then it sounds like you
defining the instance of something to be "that which is returned by
instance_of?".
It seems to me that there are two very different relationships here:
what I will call "instance" (though David might not like how I will
use it) and what I will call "superclass". These are the arrows used
both in 'ri Class' and in the pickaxe, and I think these are the
meaningful relationships. (Usually, the relationship one-to-many
relationship of 'kind_of?' is what we want, but that is built out of
one "instance" relationship, and zero-or-more "superclass"
relationships.)
When you create a singleton class for an object, you are changing the
'klass' pointer and, as I see it, changing which class it is an
instance of. What is returned by "instance_of?" does not change (and
I'm complaining about that, mind you; I'm fine with how it works), but
that object's immediate "papa" has changed.
I would also argue (I mean, it's almost the same statement) that the
objects class has changed, despite the fact that method 'class' still
returns the original class.
I think that's what Carlos is saying, and I think he's right. (And if
that's not what he's saying, then... um... I think *I'm* right! :)
I thought that the reason these methods didn't reflect the
singleton-ness under the skin of Ruby was that matz didn't want us
mucking around there. As I recall, he thought of it as an
implementation, but that he might want to change that some day. (I
think it's more of a necessity of the language than an implementation
detail, personally. When I saw that (Object)'s superclass was Class,
my mind was opened. :)
Chris
ts
C> When you create a singleton class for an object, you are changing the
C> 'klass' pointer and, as I see it, changing which class it is an
C> instance of. What is returned by "instance_of?" does not change (and
C> I'm complaining about that, mind you; I'm fine with how it works), but
C> that object's immediate "papa" has changed.
You are speaking about implementation details.
If I remember well, matz has said one day that he can completely implement
ruby without the need of the singleton class.
Forget the singleton class, for the moment :-)
Guy Decoux
David A. Black
On Wed, 20 Apr 2005, Chris Pine wrote:
>>> One possible explanation for this discrepancy is that the diagram is wrong.
>>> Another is that instance_of? doesn't take into account singleton classes.
>>>
>>> I guess it's the second one :).
>>
>> instance_of? tells you (accurately, definitively) whether or not
>> something is an instance of something. Obviously you can draw a
>> diagram that posits any relationship you wish.
>
> Then what do the sideways arrows in the 'ri Class' documentation mean?
> Carlos didn't draw that diagram, and he isn't making that up.
> Clearly, there's a meaningful relationship there.
I'm uneasy with the explanation that "instance_of? doesn't take into
account singleton classes", because, as I read it, it seemed to
suggest that what instance_of? returns is irrelevant to the question
of whether or not something is an instance of something else. I'd
rather trust the method; otherwise, I don't know where to start or
stop second-guessing the meta-information that Ruby gives me.
> See again the 'klass' arrow on page 384 (Figure 24.3) of the Pickaxe2.
>
> If "instance_of? tells you (accurately, definitively) whether or not
> something is an instance of something", then it sounds like you
> defining the instance of something to be "that which is returned by
> instance_of?".
instance_of? returns true or false; I'm just taking that literally.
> It seems to me that there are two very different relationships here:
> what I will call "instance" (though David might not like how I will
> use it) and what I will call "superclass". These are the arrows used
> both in 'ri Class' and in the pickaxe, and I think these are the
> meaningful relationships. (Usually, the relationship one-to-many
> relationship of 'kind_of?' is what we want, but that is built out of
> one "instance" relationship, and zero-or-more "superclass"
> relationships.)
The arrows in ri Class are inheritance are described as representing
inheritance, not instance-ness. (And all these relationships are
meaningful -- we're just talking terminology :-)
> When you create a singleton class for an object, you are changing the
> 'klass' pointer and, as I see it, changing which class it is an
> instance of. What is returned by "instance_of?" does not change (and
> I'm complaining about that, mind you; I'm fine with how it works), but
^^^^^^^^^^^^^^^
? :-)
> that object's immediate "papa" has changed.
And that's definitely a significant operation. It just doesn't seem
to entail a change at the "what this is an instance of" level. I can
imagine a definition or adaptation of "instance" that did refer to
both, but it appears that Matz's choice is to have the "instance of"
relationship apply only to the relationship between an object and its
"birth class".
To put it another way: in describing what happens when a singleton
class is created, it seems to me to be problematic to choose a term
which, immediately, Ruby is going to tell you is wrong. Certainly
there should be terminology for all of this (or perhaps the problem is
there's too much :-) and it's all important. I just don't want to
create a terminological inconsistency that then has to be sort of
re-explained or "asterisked" every time it comes up.
Whoops, I deleted the thing where you said that you would argue that
an object's class changes when its singleton class is created....
This is why I want Kernel#singleton_class (or Object, or wherever) --
because it's not an either-or choice. They both exist, and they
should both be (easily) referable to. I would actually be happy with
#class becoming #birth_class, and being paired with #singleton_class
(or #own_class), but one thing at a time :-)
Chris Pine
> account singleton classes", because, as I read it, it seemed to
> suggest that what instance_of? returns is irrelevant to the question
> of whether or not something is an instance of something else. I'd
> rather trust the method; otherwise, I don't know where to start or
> stop second-guessing the meta-information that Ruby gives me.
Yeah, I can definitely see your point. My view is that, in actual,
practical code, don't use 'class' or 'instance_of?' at all, use
'kind_of?'. That's almost certainly what you want, and it does take
into account singleton classes and modules (another aspect of all of
this we are leaving out). Though, if you can avoid 'kind_of?' and
just use your duck typing and unit testing, of course that's the best
thing. :)
But if you are playing around with meta-info in Ruby, it kind of seems
like you have to distrust 'class' and 'instance_of' for these reasons.
Or at least make it clear that you mean "birth class" and not "first
class in the list of things this object is a 'kind_of?'" But who
wants to give those sorts of qualifiers all over? :)
> instance_of? returns true or false; I'm just taking that literally.
Well, it seems like some interpretation is perhaps called for. As has
been noted, 'Object.superclass' return 'nil'... and we don't want to
take that too literally! <chuckle, chuckle>
<chuckle>
(I'm sorry, but that really cracked me up...)
<chuckle>
Oh, boy. If anyone else here thinks I'm half as funny as *I* think I
am, then... they... must... think I'm pretty funny. <ahem>
> The arrows in ri Class are inheritance are described as representing
> inheritance, not instance-ness.
Actually, though they are not listed as such, the sideways arrows do
not. Classes cannot have two superclasses, and a class's relationship
to it's superclass is really nothing like it's relationship to it's
singleton class (which is much more line an instance-ness
relationship).
For my OSCON talk on the Ruby Object Model (back in 2003), I used
different colored arrows for that particular picture. That really
helps a lot.
> (And all these relationships are
> meaningful -- we're just talking terminology :-)
Very true.
> > When you create a singleton class for an object, you are changing the
> > 'klass' pointer and, as I see it, changing which class it is an
> > instance of. What is returned by "instance_of?" does not change (and
> > I'm complaining about that, mind you; I'm fine with how it works), but
> ^^^^^^^^^^^^^^^
NOT complaining! NOT AT ALL complaining! Yikes...
> but it appears that Matz's choice is to have the "instance of"
> relationship apply only to the relationship between an object and its
> "birth class".
Yes, it does appear that way. I think it's a mistake how he has tried
to hide this stuff "under the rug" as it feels to me. On the other
hand, I'd have made far more mistakes in making a language, and in
practice this stuff never comes up at all.
If I were to do some serious metaclass hackery, I would certainly not
be using 'class' and 'instance_of?' anywhere. I'd use why's tools.
If I were just trying to explain how the Ruby object model works
(something I have thought a fair bit about), I would similarly avoid
them, instead talking about 'kind_of?'. And in all other cases, duck
typing is the way to go.
Given all of that, 'class' and 'instance_of?' don't seem like very
useful methods as they work now.
> I just don't want to
> create a terminological inconsistency that then has to be sort of
> re-explained or "asterisked" every time it comes up.
Amen! Although, I feel like this is already the case... :)
"Well, Ruby does say that the class is String, and we know that when
Ruby checks for methods, it starts with the class, then moves up the
inheritance chain... but really, it starts with the singleton class,
then up to any included modules in reverse order that they were
included, *then* up to String and so on..."
I feel like to really explain the topic, you kind of have to say all that.
> This is why I want Kernel#singleton_class (or Object, or wherever) --
> because it's not an either-or choice. They both exist, and they
> should both be (easily) referable to.
Agreed.
> I would actually be happy with
> #class becoming #birth_class, and being paired with #singleton_class
> (or #own_class), but one thing at a time :-)
Yeah... I'm not sure. I'm fine with it as it is, I guess because it
looks easy to a beginner (which is important for a tutorial writer
like me). It is an over-simplification, but on the surface it makes
sense. Then, when you dig down, you learn that 'class' is, in
whatever sense, not telling you the "whole" truth. That's fine, too,
because at that point you are fairly advanced, and can handle it.
I think it's great that you can do a lot of Ruby *without* having to
know this stuff.
Chris
David A. Black
On Thu, 21 Apr 2005, Chris Pine wrote:
>> instance_of? returns true or false; I'm just taking that literally.
>
> Well, it seems like some interpretation is perhaps called for. As has
> been noted, 'Object.superclass' return 'nil'... and we don't want to
> take that too literally! <chuckle, chuckle>
I think interpreting false as true in this case is a bit of a stretch
:-) I'm not "against" the idea of an object being an instance of its
singleton class in some general way. In fact, I'm fairly certain that
I once wrote something along the lines of: every object is an instance
of two classes... etc., somewhere. But if that's wrong, it's wrong; I
don't want to second-guess it.
>> I just don't want to
>> create a terminological inconsistency that then has to be sort of
>> re-explained or "asterisked" every time it comes up.
>
> Amen! Although, I feel like this is already the case... :)
>
> "Well, Ruby does say that the class is String, and we know that when
> Ruby checks for methods, it starts with the class, then moves up the
> inheritance chain... but really, it starts with the singleton class,
> then up to any included modules in reverse order that they were
> included, *then* up to String and so on..."
>
> I feel like to really explain the topic, you kind of have to say all that.
But just don't tie yourself in that knot in the first place, and then
you don't have to untie it :-) If you never say "we know that when
Ruby checks for methods, it starts with the class...." then you never
have to back out of it.
>> I would actually be happy with
>> #class becoming #birth_class, and being paired with #singleton_class
>> (or #own_class), but one thing at a time :-)
>
> Yeah... I'm not sure. I'm fine with it as it is, I guess because it
> looks easy to a beginner (which is important for a tutorial writer
> like me). It is an over-simplification, but on the surface it makes
> sense. Then, when you dig down, you learn that 'class' is, in
> whatever sense, not telling you the "whole" truth. That's fine, too,
> because at that point you are fairly advanced, and can handle it.
>
> I think it's great that you can do a lot of Ruby *without* having to
> know this stuff.
On the other hand (also from the point of view of a chronic
explainer of Ruby :-) it's easier to say: Every object has a birth
class and a singleton [or whatever] class, than: Every object has a
class and a (class << self; self; end) :-)
Douglas Livingstone
> Every object has a class and a (class << self; self; end) :-)
What is the "<<" operator called?
Cheers,
Douglas
Jim Weirich
David A. Black said:
> On the other hand (also from the point of view of a chronic
> explainer of Ruby :-) it's easier to say: Every object has a birth
> class and a singleton [or whatever] class, than: Every object has a
> class and a (class << self; self; end) :-)
A question for those familiar with Ruby internals ... does an object's
singleton class exist from the moment the object is created, or does it
spring into existence the moment it is needed to hold singleton methods?
David A. Black
On Thu, 21 Apr 2005, Jim Weirich wrote:
>
> David A. Black said:
>
>> On the other hand (also from the point of view of a chronic
>> explainer of Ruby :-) it's easier to say: Every object has a birth
>> class and a singleton [or whatever] class, than: Every object has a
>> class and a (class << self; self; end) :-)
>
> A question for those familiar with Ruby internals ... does an object's
> singleton class exist from the moment the object is created, or does it
> spring into existence the moment it is needed to hold singleton methods?
I'm pretty sure it springs into existence for the purpose, just to
avoid overpopulating object space with classes. Otherwise there would
be, say, 10000 class objects created for an array of 10000 one-byte
strings, etc. (This is based partly on some familiarity with
internals and also memory of previous discussions with people with
more familiarity with internals.)
Peter Suk
That would be very hard on GC, since you'd also be creating 10000 new
'roots' to start traversing from.
--Peter
--
There's neither heaven nor hell, save what we grant ourselves.
There's neither fairness nor justice, save what we grant each other.
Chris Pine
> be, say, 10000 class objects created for an array of 10000 one-byte
> strings, etc.
Well, it would be worse than that, actually, since singleton classes
are themselves objects, and can have their own singleton classes...
So just having a single object would cascade into an infinite tower of
singleton classes, until you ran out of memory.
However, I think that when you create a class with "def class", it
always creates the singleton class then.
Chris
why the lucky stiff
matz calls it the "singleton class notation".
<http://www.google.com/search?&q=matz%20%22singleton%20class%20notation%22>
_why
Douglas Livingstone
>
> matz calls it the "singleton class notation".
> <http://www.google.com/search?&q=matz%20%22singleton%20class%20notation%22>
>
Heh, looks like the quotes aren't optional either :)
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/40537
Cheers _why, thanks for the tuts too :)
Douglas
gabriele renzi
ah! this is something I always wanted to know, I've been always thinking
on the lines of "why are'nt method just defined in the object? do we
need this singleton class thing?"
Lyndon Samson
Since there is no such thing as metaclasses in ruby ;-)
<quote>
|I've been trying to understand metaclasses
You don't have to, because there's no such a thing in Ruby.
In Smalltalk, a metaclass is a class of a class.
In Ruby, the Class class is the class of all classes, no metaclass.
But every object (of course including classes) can have hidden
meta-object (the place holder for singleton methods), which is only
revealed by the "singleton class notation".
</quote>
from http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/40537
ts
g> ah! this is something I always wanted to know, I've been always thinking
g> on the lines of "why are'nt method just defined in the object? do we
g> need this singleton class thing?"
Well, if you want a more stupid explanation (it's easy for me to be stupid
:-))
* a module is an object which can store (define) methods
* a class is a module which can use inheritance
* for classes, you have
- "birth" class which can create instance
- "singleton" class which is always associated with only one object
and no, a "singleton" class is not a "birth" class.
And in smalltalk terminology, ruby has only one metaclass : it's Class.
Guy Decoux
csaba
David A. Black wrote:
> I always thought it was singleton in the sense that, unlike the
"birth
> class", it was not shared with other objects. There is of course a
> long history of discussion about the term "singleton", and the fact
> that it's overloaded.... I've suggested "own class", and others have
> suggested other terms, though I don't know that even a pronouncement
> from Matz will change usage completely.
"Own class" is the best I've heard 'till now in terms of correctness,
it's just a bit "pale". I mean, when you say "I go there by my own
car", then the "own" doesn't refer to a special type of car, it just
refers to some relation of the car with other things. It refers to a
non-intrinsic thing. But if you say
"I go there by my batcar", that makes a difference. Such a thing is
what we need for ruby.
What about "eigenclass", like in eigenvalue?
Mark Hubbart
I think you're right about "own class". The most defining
characteristic of "singleton classes" is probably not that they only
have one instance, but that only one instance has *them* :) They are
the personal, or private class of that object. a jaunt through a
thesaurus gives a few possible synonyms for "own class":
- personal class
- private class
- exclusive class
- reserved class
I'm not sure "personal" works when referring to objects (or classes);
it sounds like an attempt to anthropomorphize them.
"private" might be good, though it might be confusing, what with
public/private methods. But it couldn't be more confusing than
"singleton class" vs "Singleton class" :)
"exclusive", I'm not sure if it sounds right, or has the right shade
of meaning. "reserved" either.
What do you think of "private class"? Or is there some other
definition I'm missing that would preclude that? Would that be a good
overloading of terms?
cheers,
Mark
Trans
> definition I'm missing that would preclude that? Would that be a good
> overloading of terms?
Problem with that is a concept that has been foward for classes that
are not visible outside a given scope. eg.
class X
private class Y
# ...
end
# ...
end
Not that Ruby has them (yet ;-) but that would most certainly be
called a "private class".
I had been holding on to the term "special class", but I suppose that
makes it sound like it has "special" needs :-) Perhaps we should try a
differnt tact, like "root class" or "direct class".
T.
Ryan Leavengood
>
> I had been holding on to the term "special class", but I suppose that
> makes it sound like it has "special" needs :-) Perhaps we should try a
> differnt tact, like "root class" or "direct class".
What about "shadow class"? Because it is like it is there, but not really.
Ryan Leavengood
Lyndon Samson
ILC - Instance Local Class? A variation of Thread Local Storage.
> T.
>
>
--
Into RFID? www.rfidnewsupdate.com Simple, fast, news.
Mark Hubbart
On 4/21/05, Lyndon Samson <lyndon...@gmail.com> wrote:
> On 4/22/05, Trans <tran...@gmail.com> wrote:
> > > What do you think of "private class"? Or is there some other
> > > definition I'm missing that would preclude that? Would that be a good
> > > overloading of terms?
> >
> > Problem with that is a concept that has been foward for classes that
> > are not visible outside a given scope. eg.
> >
> > class X
> > private class Y
> > # ...
> > end
> > # ...
> > end
> >
> > Not that Ruby has them (yet ;-) but that would most certainly be
> > called a "private class".
I know Java has private classes (or is it just inner classes?), but
I've never heard anyone ask for them in ruby before. Private classes
in that sense really don't seem very rubyish to me. If we'll never
have private classes in that sense, then it leaves the term open. So
that part of it would depend on the chances of Ruby ever having
limited scope classes.
> > I had been holding on to the term "special class", but I suppose that
> > makes it sound like it has "special" needs :-) Perhaps we should try a
> > differnt tact, like "root class" or "direct class".
"direct class" isn't bad. I would expect "root class" to be Object, though.
> ILC - Instance Local Class? A variation of Thread Local Storage.
This one seems a little verbose to me. maybe just instance class?
cheers,
Mark
David A. Black
I don't know... it may be time for a little paleness in the
terminology. All the snazzy, exciting terminology seems to cause
problems :-)
> What about "eigenclass", like in eigenvalue?
But eigen is just German for own. I'd rather just keep it in English.
Austin Ziegler
Star Chamber Class?
-austin (scnr)
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Martin DeMello
I like 'shadow class', since you can think of it as shadowing the #class
class. 'Eigenclass' was nice too, since 'eigen' has a long and
honourable tradition of being borrowed into English words.
martin
David A. Black
I think that might happen sometimes for some particular reason having
to do with the history of usage, but just translating into German out
of the blue seems peculiar to me.
Douglas Livingstone
>
> > I like 'shadow class', since you can think of it as shadowing the #class
> > class. 'Eigenclass' was nice too, since 'eigen' has a long and
> > honourable tradition of being borrowed into English words.
>
> I think that might happen sometimes for some particular reason having
> to do with the history of usage, but just translating into German out
> of the blue seems peculiar to me.
>
But don't you know that random german words are "supremely chique.
handsome beyond description. geeky, yet bodaciously amazing"? [1]
Douglas
James Britt
So long as it has an umlaut, I'm happy.
Rüby: For Heavy Metal Coding
Why not use Japanese words or prefixes?
James
Sy
> So long as it has an umlaut, I'm happy.
>
> Rüby: For Heavy Metal Coding
I can't believe you invoked the heavy metal umlaut[1] .. that's hilarious! =)
Hal Fulton
+1
Snickering out loud.
Hal
James Britt
> On 4/21/05, James Britt <jam...@neurogami.com> wrote:
>
>>So long as it has an umlaut, I'm happy.
>>
>>Rüby: For Heavy Metal Coding
>
>
> I can't believe you invoked the heavy metal umlaut[1] .. that's hilarious! =)
That's right!
I expect to be seeing devil-horn hand-signals from the crowd at RubyConf
this year.
James
Ryan Davis
You're on! :P
(I wonder if we can get limozeen to play at the conference--hrmmmm)
Jonas Hartmann
> But eigen is just German for own. I'd rather just keep it in English.
http://dict.leo.org/?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&relink=on§Hdr=on&spellToler=std&search=eigen
http://dict.leo.org/?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&relink=on§Hdr=on&spellToler=std&search=own
"eigen" can mean much more.
try some latin/roman word ;p
--
ionas
:: someone who got no single clue about metaclasses at all ;-(
David A. Black
On Sat, 23 Apr 2005, Jonas Hartmann wrote:
>>> What about "eigenclass", like in eigenvalue?
>> But eigen is just German for own. I'd rather just keep it in English.
> it is also but not only:
> http://dict.leo.org/?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&relink=on§Hdr=on&spellToler=std&search=eigen
> http://dict.leo.org/?lp=ende&lang=de&searchLoc=0&cmpType=relaxed&relink=on§Hdr=on&spellToler=std&search=own
>
> "eigen" can mean much more.
Naja, weiss ich schon :-) I was oversimplifying. But it still feels,
I don't know, _fremd_ with respect to the texture of Ruby.
> try some latin/roman word ;p
I was actually thinking about "idioclass", but decided the debate that
would ensue was too predictable to bother actually instigating :-)
Trans
I was thinking that maybe we should look at how we get at the class
now:
(class << self ; self ; end)
that would indicate a name like "selfish_class" :-)
And really the class is quite egotistical. What right does it have to
butt in so _easily_? Isn't that exactly why Matz is reluctant to settle
on a final name? On the other hand "selfish" is a little "ishy" too --I
mean, is it or isn't it? So perhaps "egotisitical_class" would do. A
little long. We could shorten to just "egoclass". Ah, yes. Now that's
fun. Now I can speculate on what is "superegoclass" :-) Freud would be
proud.
Okay, cheese humor aside, "idioclass" is actually a very good term. It
is quite percise, even better than "special_class" I think.
Main Entry: idio-
Function: combining form
Etymology: Greek, from idios -- more at IDIOT
: one's own : personal : separate : distinct <idioblast>
And it has a nice technical ring too it. Which is really what all the
other suggestions lacked. Good call David.
+1
T.
Mathieu Bouchard
while the remaining parts are likely unreadable without MIME-aware tools.
Mathieu Bouchard
Mathieu Bouchard
Mathieu Bouchard
Mathieu Bouchard
ts
M> 2. the Object class just happens to be the place where .new() is defined
no,
Guy Decoux
gabriele renzi
>
> On Thu, 21 Apr 2005, ts wrote:
>
>> * a class is a module which can use inheritance
>
>
> Module#include qualifies as inheritance, no matter how one may try to
> hide it under a carpet. A dog with a leg missing is still a dog. It
> doesn't matter how much the Java religion asserts that multiple
> inheritance is bad. We merely have to assert that multiple inheritance
> is good, instead of playing word games like what I've consistently heard
> in the Ruby community in my five years of hanging around. The attempt to
> attract Java programmers to Ruby shouldn't have been done by
> compromising the simplicity of Ruby; instead it should have been done by
> cult deprogramming.
>
I disagree, thinking that mixins and multiple inheritance are not the
same thing, and should not be pointed as such.
> The defining qualities of a Ruby class may be that:
>
> 1. a Ruby class is a direct-subclass-of a Ruby class using the "<"
> notation (except the Object class).
>
> 2. the Object class just happens to be the place where .new() is
> defined; and this is no matter how many classes use undef_method(:new)
> to forbid instantiation.
Is'nt it Class#new ?
gabriele renzi
>
> On Thu, 21 Apr 2005, gabriele renzi wrote:
>
>> ah! this is something I always wanted to know, I've been always
>> thinking on the lines of "why are'nt method just defined in the
>> object? do we need this singleton class thing?"
>
>
> Because of backwards-compatibility with C++/Java/Perl/Python programmers.
>
> Most backwards-compatibility issues occur wrt the _programmers_ and not
> so much wrt the _programmes_.
>
I don't understand, sorry.
Python programmers for sure can define singleton methods directly in a
object without singleton classes, I guess perl folks too, since an
object is mostly an hash (I may be wrong, not really good at perl).
Actually, only Java's anonymous classes seem somewhat similar to
singleton ones.
I agree with you that some backward compatibility issues may be
programmer-based, but I don't think this is a case.
David A. Black
You wrote:
> On Thu, 21 Apr 2005, gabriele renzi wrote:
>
> > ah! this is something I always wanted to know, I've been always
> > thinking on the lines of "why
> > are'nt method just defined in the object? do we need this singleton
> > class thing?"
>
> Because of backwards-compatibility with C++/Java/Perl/Python
> programmers.
Is this something you have real reason stood behind Matz's design
decisions, or is it just an unkind jab at a design you don't happen to
like?
Mathieu Bouchard
Mathieu Bouchard
Mathieu Bouchard
gabriele renzi
>
> On Sun, 24 Apr 2005, gabriele renzi wrote:
>
>> Mathieu Bouchard ha scritto:
>>
>>> On Thu, 21 Apr 2005, ts wrote:
>>>
>>>> * a class is a module which can use inheritance
>>
>> same thing, and should not be pointed as such.
>
>
> (call-next-method) macro works in LISP and then you won't be able to
> honestly tell me that mixins are not inheritance and that Ruby's mixins
> aren't like Lisp's classes. Really. Go see for yourself.
I'm not much into CLOS, but IIRC the basic approach is to linearize the
ancestors (not thinking of MOP, method combination and so on).
I can agree this yields similar result to our mixin strategy, but I fail
to see how it shows mixins are MI.
It would at best show that CLOS' MI is similar to ruby's mixins.
If I would talk about how Eiffel or C++ handle the problem differently
would that prove my they MI!=mixins, or would show that CL has not MI or
simply that there are diferent approaches to the problem?
You snipped out (or I misquoted it) the part I was actually referring:
>> Module#include qualifies as inheritance, no matter how one may try to
>> hide it under a carpet. A dog with a leg missing is still a dog.
The core idea of MI (to me) is the ability to inherit two things that
would need to be instantiated, while using mixins this is impossible.
And a man with big ears do not qualify as a rabbit to me .
>>> 1. a Ruby class is a direct-subclass-of a Ruby class using the "<"
>>> notation (except the Object class).
>>> 2. the Object class just happens to be the place where .new() is
>>> defined; and this is no matter how many classes use
>>> undef_method(:new) to forbid instantiation.
>>
>> Is'nt it Class#new ?
>
>
> Sorry, yes. But it amounts to the same thing, because the (Object)
> metaclass is the sole direct descendant of Class, and the creation of a
> new class never can add a new direct descendent to Class, and so it
> would be possible to unify the (Object) metaclass and the Class class
> and frankly no-one would notice.
>
> Guy Decoux and you are right on this detail, but this detail is not
> important in my point,
neither was in mine, just a note :)
> and here is what I mean: I mean that what makes a
> class a class is that it inherits from whatever is the sole authority
> for making new objects, and that's something that non-class modules
> don't have access to.
>
> (And although there *are* some pieces of code that might construct new
> objects without the help of Class#new, it isn't the one you can use for
> building objects of your own custom-designed non-singleton classes)
>
> Does that clear up things a bit?
I think I understood this, *this* is what I think as the difference
beetween mixins and MI :)
Christian Neukirchen
> On Sun, 24 Apr 2005, gabriele renzi wrote:
>> Mathieu Bouchard ha scritto:
>>> On Thu, 21 Apr 2005, ts wrote:
>>>> * a class is a module which can use inheritance
>> I disagree, thinking that mixins and multiple inheritance are not
>> the same thing, and should not be pointed as such.
>
> Take a look at the inheritance mechanism in CommonLISP and how the
> (call-next-method) macro works in LISP and then you won't be able to
> honestly tell me that mixins are not inheritance and that Ruby's
> mixins aren't like Lisp's classes. Really. Go see for yourself.
Sadly, mixins *arent* MI. They often are enough, but not always.
Can you inherit from Modules? How do I specialize a mixin?
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
gabriele renzi
>> I guess perl folks too, since an object is mostly an hash (I may be
>> wrong, not really good at perl).
>
>
> No: in Perl, a hash can contain anonymous subs (that is like Ruby
> procs), but the method lookup is a different thing.
<snip>
sorry, I did not intend that you could handle they the same way.
I was justthinking that in python an object is basically an hash
(actually visible from it's __dict__ attribute) and that there is some
magic for the calling.
Since I recall that perl's OO was inspired from python I was *guessing*
there could be a similar mechanic.
>> Actually, only Java's anonymous classes seem somewhat similar to
>> singleton ones.
>
>
> They are not. They are a special case of inner classes, and inner
> classes blend the concepts of class, delegation, and closure, all
> together, but nothing in Java is singleton. But still I am curious:
> could you please provide a snippet in which you emulate singleton
> behaviour using Java's anonymous classes?
I was thinking of:
Object a= new Object() {
public String toString(){
return "method ovverriden for this single object";
}
};
System.out.println(a); // => method ovverriden for this single object
like in ruby lookup happens like:
- loon in singleton class
- then in superclasses
in java the lookup becomes
- look in anonymous class
- then in its superclasses
Christoph
>>
>
> I disagree, thinking that mixins and multiple inheritance are not the
> same thing, and should not be pointed as such.
I tend to agree with Mathieu that the semantically insistence that
Ruby's mixins
are NOT some kind of MI of presents itself as a language game to
apiece the java kraut. On the other hand Ruby’s "Module mixin" relation is
NOT transitive, making it strikingly different from (single or multiple)
inheritance (see for example [ruby-talk:32007])
>
>> The defining qualities of a Ruby class may be that:
>>
>> 1. a Ruby class is a direct-subclass-of a Ruby class using the "<"
>> notation (except the Object class).
>>
>> 2. the Object class just happens to be the place where .new() is
>> defined; and this is no matter how many classes use
>> undef_method(:new) to forbid instantiation.
>
>
> Is'nt it Class#new ?
Mathieu might be nominally wrong, but he is right in pointing out that
the current distinction between
"meta Object" (the singleton class of the "Class" object "Object") and
the class "Class" is just an artifact
of the current implementation of Ruby’s Object model. Two or three years
ago I even cooked up a
semi working modification of the interpreter (translation: the resulting
interpreter finished without crashing
running a couple of simple scripts), such that "meta Object" == Class
was true.
The strongest argument against "meta Object" == Class are the current
class relations
Class < Module < Oject.
To resolve this we could subclass both Module and Class from Object
directly, or settle on relations
Module < Class < Object
Another possibility, would be getting rid of the class Module
altogether, by either relying on full-blown MI
or restricting the mixins to special "Module classes". Any of these
alternative schemes have their shortcomings,
but the current Class < Module < Object isn't flawless either.
/Christoph
Christoph
>
> I'm not much into CLOS, but IIRC the basic approach is to linearize
> the ancestors (not thinking of MOP, method combination and so on).
> I can agree this yields similar result to our mixin strategy, but I
> fail to see how it shows mixins are MI.
Linearizing a method lookup of ancestor (sort of) graph is
+ merging of ancestor graphs is the hall mark of MI to me.
> It would at best show that CLOS' MI is similar to ruby's mixins.
> If I would talk about how Eiffel or C++ handle the problem differently
> would that prove my they MI!=mixins, or would show that CL has not MI
> or simply that there are diferent approaches to the problem?
>
> You snipped out (or I misquoted it) the part I was actually referring:
>
> >> Module#include qualifies as inheritance, no matter how one may try to
> >> hide it under a carpet. A dog with a leg missing is still a dog.
>
> The core idea of MI (to me) is the ability to inherit two things that
> would need to be instantiated, while using mixins this is impossible.
This sounds more like C++'s idea of MI (to me).
/Christoph
David A. Black
On Mon, 25 Apr 2005, Christoph wrote:
> The strongest argument against "meta Object" == Class are the current class
> relations
> Class < Module < Oject.
> To resolve this we could subclass both Module and Class from Object directly,
> or settle on relations
> Module < Class < Object
I know there's this perhaps odd circularity, and singularity, at the
top of the model. But does it really need to be resolved? I've
always felt comfortable living with this as the price of bootstrapping
the rest of the model.
Christoph
> I know there's this perhaps odd circularity, and singularity, at the
> top of the model. But does it really need to be resolved? I've
> always felt comfortable living with this as the price of bootstrapping
> the rest of the model.
One way or another you need to sort of bootstrap any (alternative) object
model too. I also tend to agree that the case for resolving anything is not
all that strong, especially since I kind of like unresolved
singularities:-) and
since they are probably unavoidable anyway (sort of like the singularity
marking the "beginning" of the time-space continuum).
My point (and Mathieu’s I believe) was that the validity of the average Ruby
script or even library would not be affected by some, even radical,
changes on the
top of the object model. Matz in fact changed the "method lookup path" of
”singleton classes" and especially "singleton singleton class" in the
past and I'll
bet hardly anybody noticed it.
/Christoph