is Missing multiple inheritance in sqeak a drawback ?

Alan Kay squeak-dev at lists.squeakfoundation.org
Sat Oct 12 06:15:25 UTC 2002


Hans --

At 11:56 PM +0200 10/11/02, Hans Beck wrote:
>Hi,
>
>>What multiple inheritance is supposed to do is good and is needed. 
>>But, in practice, it is very unwieldy, etc. I think there needs to 
>>be a kind of "mixing algebra" that would make the semantics of 
>>combination clear.
>>      In any case, I think there is a much better way for almost all 
>>cases, and that is multiple perspectives. I have mentioned 
>>Goldstein's and Bobrow's PIE system (done at PARC in Smalltalk in 
>>the late 70s, and some of the papers are available). The current 
>>Squeak etoy system has a gesture towards this approach. The basic 
>>idea is to make the description of a object be in terms of 
>>"perspectives" or "roles" (for example, that of being an object, of 
>>being a graphical entity, of being a collection, of having several 
>>roles in a particular model, etc.) This is a "sideways" approach to 
>>what multiple inheritance does, but for many of the most important 
>>cases does not require any kind of inheritance at all (e.g. what 
>>class object now supplies in the hierarchy, it supplies as a 
>>perspective). Several nice things about this way of looking at 
>>things is that it doesn't stop one from using inheritance, it gets 
>>rid of inheritance for lots of cases, it makes things clearer, it 
>>separates concerns for complicated objects. Another ramification of 
>>this POV is that it encourages a different way to look at 
>>parameterization and variants without requiring subclassing, etc.
>>
>
>at first reading, this let remember me to that what is called aspect 
>oriented programming. Is there some relation of this to 
>"perspectives " ?

There is likely a lot of relation. Gregor Kiscales was one of the MOP 
authors with Bobrow, and one of the driving force behind today's 
"aspects". I should mention that "aspects" originally was used for a 
next step on the "perspectives" ideas, but gradually became the name 
of the somewhat different approach of AOP today.

>
>A second point: the other postings an yours sketched systems with no 
>inheritance at all. Hmmm. As you describe the "roles", this is 
>thinkable, but if we get rid of inheritance, don't we get rid of the 
>powerful method top-down or from the way coarse to the details ? If 
>I look how I design software in UML and squeak (which may be not the 
>best way of course) I often take advantage of thinking top down, or 
>let me saying as a thesis, of thinking evolutionary.  If I had no 
>inheritance and only roles instead of it, than these roles must be 
>already developed, with no need to further evolution ? Can you see 
>what I mean ?

Sure, and remember I didn't say we should get rid of inheritance -- 
but I did imply that we've tried to use inheritance for too many 
things, and that giving it up while designing can produce great 
benefits. It's likely that there is a different and better way to 
think about even the good stuff that inheritance accomplishes.

Cheers,

Alan

----



>
>
>Greetings
>
>Hans


-- 



More information about the Squeak-dev mailing list