Stephen --

At 7:06 AM -0000 1/3/99, Stephen Pope wrote:
-- snip --
>> There is a cooler and most interesting way to approach all this.
>> [...]
>> it was called PIE: Personal Information Environment
>> [...]
>> The basic idea is to have an object made up of multiple perspectives...
>
>PIE was much more of a frames-like knowledge representation [KR] framework,
>rather than a concrete OO implementation platform. I believe it's quite
>important to differentiate between the two. OO ~= KR! (ByTheWay, the best
>of the
>PARC Blue Books on the subject is Danny bobrow's "Knowledge Representation,"
>which was still available from PARC when last I asked.)

This is true and the "frames" aspect of their work was the weakest part
(but I think their approach was also in the LISP tradition that they were
used to, so it came out more data-structure centric than is good for real
OOP).

>There are times when "real" MI is handy (e.g., Sea-plane is-a Plane, is-a
>Boat),
>and other times when composition/delegation (e.g., EventList is-a Event, has-a
>Event-collection) or class/species differentiation (e.g., HertzPitch is-a
>NumericalMagnitude, species-is-a Pitch) work better and result in cleaner,
>more
>reusable, code. Remember also that the Smalltalk class library is not
>structured
>as "mix-ins," so it's not set up for MI of (e.g.,) magnitude, collection, or
>stream protocols.

I believe that the lack of an "MI algebra", so that quite a bit of the
meaning of a mix can be determined by contemplating the symbolic statements
that set up the MI, is the real reason why much MI winds up being more
trouble that it's worth. What you don't want to have are structures in
which the programmers have to remember ideosyncratic features of ordering
that must be preserved. I also think that "slot classes" ala Pat Winston (I
think I've mentioned them previously on this list) are both useful and
needed in any MI scheme.

Cheers,

Alan