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
|