In many ways, "sideways" aspects are very interface like, e.g. one would
expect a class to implement them (declare that they intend to support that
aspect/interface) and one would expect to be able to test an object for
support for an aspect/interface.  It gets alittle tricker in terms of
whether aspects need to rename/redirect messages to implementation (I
believe the answer is yes).  

-----Original Message-----
From: Alan Kay [mailto:Alan.Kay at disney.com]
Sent: Thursday, March 16, 2000 6:27 PM
To: squeak at cs.uiuc.edu
Subject: Re: String hierarchy (was: UTC-8 (was ...))


Maurice --

At 5:19 PM -0800 3/16/00, Maurice Rabb wrote:
-- snip lots of details --

>I know that this may be viewed as blasphemy, but this is another
>compelling reason that String should be removed from the Collection
>hierarchy.  IMHO, the continued inclusion of String in the Collection
>hierarchy is a serious mistake that continues to beget problems.
>
>Including in the Collection hierarchy not only reveals its
>implementation but forces its type.  It forces an "is-a" relationship
>instead of a more appropriate "has-a" relationship.  Though strings
>often _act_ as collections, they are more than just collections.  All
>that should matter is that strings should be able to answer
>aSequenceableCollection of its contents when the appropriate message
>is sent; e.g. #characters|#elements|#contents.

To me, this is an even better example of why we should eventually (pretty
darn soon) put "sideways" aspects into Squeak a la the nice old PIE system
of Goldstein & Bobrow (done in Smalltalk-76 at PARC in the late 70s).
     The problem here is that class hierarchies are often (to me almost
always) a poor way to express complex relationships and roles. I think
aspects are a better way to handle some of these problems than multiple
inheritance, though both cover some of the same ground.
     Aspects are also a pretty good way to deal with situations where we
now use wrappers e.g. MorphicWrappers and Players....

Cheers,

Alan