From: dblack@... Date: 2002-12-13T07:04:28+09:00 Subject: Re: do I really not understand inheritance?? Hi -- On Fri, 13 Dec 2002, Chris Pine wrote: > 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 Interesting -- I perceive it as more machinery :-) > 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. Well... yes, but one could say the same thing about dividing by zero :-) I should probably reread some of this thread, because I can't figure out how subclassing Class got into the discussion. > 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.) I haven't experienced any of these problems... but in any case, I don't think I'd connect this with multiple inheritance. In fact, I think comparisons between Ruby's design and other designs, while sometimes helpful to bootstrap learning, usually end up being an impediment. When people ask whether modules are the same as multiple inheritance, or class methods are the same as static whatever methods in Java (sorry, I'm Java illiterate), and so on, the answer is usually, "You can get a foothold by looking at it that way, but not really." Singleton classes as multiple inheritance doesn't ring true to me. > - 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! I've never seen matz say that using them for their primary purpose (creating singleton methods on objects) is abusive, only other things. (I'm still waiting for a 10-word post from matz that will set all of us straight :-) > - 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. Modules are designed perfectly for exactly that. > - 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. I'm wary of anything that promotes the idea of the "true class" of objects in Ruby... though, as I said before, I'm intrigued by the idea of being able to take a kind of snapshot of an object and inferring a class object from it. But I don't see any reason why there would have to be a choice between that and the per-object-oriented (so to speak) model of Ruby. OK, enough banter :-) You should hack the interpreter to your liking and show us some examples of things that are easier to write and/or read. And I should see if I can create my class snapshot thingy. David -- David Alan Black home: dblack@candle.superlink.net work: blackdav@shu.edu Web: http://pirate.shu.edu/~blackdav