Re: ECOOP Reaction to CLOS

[Kelley.pa@Xerox.COM]

> The CLOS proposed standard explicitly claims in general to obey the
> implicit inheritance - explicit override rule, but it does not for

|I couldn't find a reference to "implicit inheritance - explicit
override"
|in Part 1 of the 87-002 spec. What page is it on?

I was refering primarily to page 1-7, the first paragraph both under
Inheritance of Methods and Inheritance of Slots and Slot Options.
Obeying implicit inheritance in general is claimed there (though
explicit override is implicit :-).  The implication that the rule was
quoted as such in 87-002 was unintentionally misleading -- one too many
explicits in my original statement.

| ... the object essentially has duplicate
|copies of logically the same state. This approach was used in
|CommonObjects, and is one aspect of CommonObjects which seems to bother
|programmers the most. ...

If inheritance of methods with the same name in CommonObjects signals an
error, that is inconsistent with its slot inheritance. 

|The problem here is that every algorithm for multiple inheritance loses
|somehow. ... If tree-structured multiple
|inheritance is used (where the entire tree of supers
|is maintained, duplicating branches above joins) then duplicated state
|occurs above join classes....

Based on the arguments in Snyder's OOPSLA 86 paper, I would claim this
problem is really a feature in disguise.

At any rate, presenting the effects of the proposed inheritance
algorithm for CLOS would be more understandable if in conjunction with
presenting the class ordering algorithm, violations of the "implicit
inheritance - explicit override" rule are clearly marked as such.

 -- kirk