From: Bob Hutchison Date: 2005-09-30T22:24:07+09:00 Subject: Re: Operator Overloading << On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote: > On 9/30/05, Robert Klemme wrote: >> Pardon me, but this is nonsense: Matt has *inherited* Array. Of >> course >> you can argue about whether *that* is reasonable, but once you did >> that >> providing your own implementation of a super class method in a >> derived >> class is completely standard OO. There's even a keyword to >> support this >> ("super"). >> > > And all of that still works with Delegate. I know, because I *just* > did it for some code that won't see the light of day for a while. > > >> If you wanted to question the practice of inheriting classes like >> Array >> and String then I'm completely with you. This doesn't make sense >> more >> often that it does. But I know too little of this particular case to >> further comment on that. >> > > That's really what I was trying to say here. Yes, the idea is *don't* > inherit from Array. You can't overload in Ruby, you can override and > you have to call super to make it work, or you have to call it > directly with aliasing. Where do you stop? Why inherit at all? How do you decide? [I sympathise with this, I've always preferred composition to inheritance. Worse still, I went to the OOPSLA'87 (Orlando anyway, think it was 1987) conference because I didn't 'get' OO and was hoping to figure it out. I mentioned this to someone I was sitting beside and was treated to a lesson over lunch (maybe breakfast, can't remember). This person was David Unger, one of the key people responsible for self and the alternate OO model, delegation/ prototype, to Ruby's class-based OO model. So I was indoctrinated early by one of the best :-) The "Treaty of Orlando" came out of that conference.] Cheers, Bob ---- Bob Hutchison -- blogs at Recursive Design Inc. -- Raconteur --