----- 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. Or, to put it another way: it isn't broken :-) ---------------------------- 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. :D 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).