<DISCLAIMER>
I don't claim to fully understand what Alan is saying specifically, but
comments are general enough to not really matter much.
</DISCLAIMER>

Having the concept of roles from the beginning doesn't hinder the
evolution of the system.  This is just like the effect of a good CRC
session before any development is done.  Roles are free to morph,
combine, split, delete, etc., just as you are free to rip up any and all
of the CRCs and start again.  The idea is to be flexible enough to allow
the system to evolve on its own.  This is a tenet of most (if not all)
agile methodologies and I can testify to its power and effectiveness.

=jason

On Fri, 2002-10-11 at 17:56, 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 " ?
> 
> 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 ?
> 
> 
> Greetings
> 
> Hans
> 
> > 
> 
> 
> 
> 
>