Or, to put it another way: it isn’t broken 
···
----- Original Message -----
From: dblack@candle.superlink.net
True, this isn’t a problem if you don’t allow Class to be subclassed;
Class.new is only broken if you remove the checks which prevent you from
noticing it’s broken… er, so to speak.
Exactly! Maybe it didn’t sound like it (my fault), but that is what I was
trying to say. “Broken” was meant to be very tongue-in-cheek. I mean, I
was essentially saying, “It’s broken, but there’s no way of knowing it.”
That’s my idea of a joke. 
Sorry if that wasn’t well-conveyed; just my
peculiar sense of humor, I suppose.
But, if I’m correctly abstracting your underlying idea, I can imagine (at
least theoretically) that it might be good to be able to sort of take a
snapshot of an object’s behavior and capture it in/as a class.
In a sense, that’s already happening (if I understand you); it’s just not a
“class” class, it’s a singleton class.
I wanted to see if we could have the same functionality (the ability to
extend a single object) without the additional machinery of singleton
classes. I just thought that less machinery would allow for a more elegant
solution. I think I described a system pretty well in 58785 (which I don’t
think was archived because the archiving computer was down… it’s the one
with all of the diagrams). Assuming that you could subclass Class (and that
doing so worked properly), it would make sense and perhaps even allow all
sorts of new things we haven’t yet though of. (It seems like Ruby has
usually tried to avoid making unnecessary restrictions on what is allowed in
the language.)
At this point, I’d like to state that I’m not saying that such a change
would be worth the effort from cost/benefit statndpoint. But just for the
sake of argument:
If this system were implemented, what would we lose?
-
Extended objects would not be singletons of a singleton
class. But why is that important? This would just be
giving us a new option, as I see it: the ability to
create a new object with the properties of the extended
object. -
In some cases, current occurrences of the #class method
would have to be changed to the #kind_of? method. This
doesn’t really seem like much of a problem, though. -
The Singleton module wouldn’t work properly. This is
(as I currently see it) the biggest argument against
what I am suggesting. However, it would certainly be
possible to implement this at the interpreter level,
just not at the Ruby level. Being a singleton would
probably be more a property of a class, rather than a
mixin. It would also mean that you wouldn’t be allowed
to extend a singleton object… but why would you ever
need to? You could just extend its (singleton) class,
instead. -
Some other things which only matz could bring up.
And what would we gain with such a system?
-
Little intuitive niceties, like having #kind_of? being
simply an issue of looking in an object’s class’s
ancestors, or having an object’s class describe all of
the behavior of that object. This is where the seams
in Ruby’s object/class model begin to show. The issue,
as I see it, it that basically singleton classes are a
form of multiple inheritance, which can’t help but
cause problems. (Perhaps only small ones, but still.) -
A simpler object/class model. Part of what is so great
about Ruby is that clean design leads to wonderful,
though often unforseen, results. If the design can be
just a little cleaner still, it seems to me only a good
thing. No more messing around with hidden singleton
classes which matz considers abusive, anyway! -
We can still extend objects using the exact same syntax.*
In my eyes, extending an object and creating a singleton
are really orthogonal concepts. We could still extend
objects; we just wouldn’t be making them singletons at
the same time. -
More freedom as programmers. We’d be able to interact
with the true class of an object (not some weird, hidden
multiple inheritance thing). We’d be able to subclass
Class. In general, I think we would get more unforseen
goodness.
This is what I love so much about Ruby: a simple, clean language allows for
all sorts of unforseen goodness.
Chris
- About that syntax… currently the “class << foo; …; end” construct
creates a new singleton class if one didn’t already exist. If it did exist,
however, the code simply extends the class. We could keep this behavior by
allowing each object to create only one class in this way. (This is not
the same as having a singleton class, which can only instantiate one
object… it’s sort of the reverse.) However, if this new system were in
place, perhaps we would find more natural ways to express object extension
(without placing unusual, singleton-esque restrictions).