Milan,
Yes, I am confident that traits is an important part of our future. Give me 
a few months, and I can (hopefully) be more specific about where I believe 
it fits in.

Trygve


At 23:22 30.01.2005, you wrote:
>Trygve,
>
>yes! one note/question - do you think using Stef's (at all) Traits would
>replace the need for interfaces and/or delegation or do you see something
>inheritent in having interfaces that Traits would not cover (because I assume
>Trait's provide what delegation can give us). [Well in any case it's time for
>me to start playing with Traits, loaded the new version this wekk but not
>time ...]
>
>Milan
>
>
>
>On January 30, 2005 09:52 am, Trygve Reenskaug wrote:
> > Hear, hear!
> >
> > Subclassing is generally evil with two exceptions:
> > 1) When subclassing a stable core.
> >     The only way for core classes to evolve is by creating
> >     new classes with new names.
> > 2) When a developer creates super- and subclass simultaneously.
> >
> > The Squeak programming environment needs to be extended with support
> > for  Interfaces. A great deal of what we today do with subclassing should
> > be done with delegation.
> >
> > Finally, the notion of a Component as an object that encapsulates other
> > objects looks promising for program sharing; more robust than the code
> > based Package.
> >
> > Cheers
> > --Trygve
> >
> > At 11:20 30.01.2005, Peter wrote:
> > >[...]
> > >-- another way --
> > >
> > >1. Throw away the notion that you can depend on that big, juicy class
> > >library.  You can't, and it's a mistake to try, because it will evolve
> > >faster than you can keep up and your code will rot.
> > >
> > >2. Decide on a very small, stable core.  Collection and number classes may
> > >be a good start.
> > >
> > >3. Introduce a proper notion of interfaces for these.  Freeze the
> > >interfaces, either formally or by people avoiding modifying them.
> > >
> > >4. Build up from this core.  In each package - for example, the MVC UI -
> > >define and freeze interfaces.  Document all the dependencies.  Ensure each
> > >package can be loaded into an image that only has its dependencies loaded;
> > >and ensure that a package *cannot* alter any other package.  Yes, this
> > >means that nobody except the maintainer of the core can touch Object, for
> > >any reason, no matter how apparently noble.
> > >
> > >We will then have a basis for a system that might begin to satisfy (2)
> > >above.  (1) will only happen when another (non-SqC) group of people get
> > >together and decide to use Squeak for a project.  The larger community
> > >cannot force it.
> > >
> > >Note that by making a system that is suitable for parallel development by
> > >many developers, we have thrown away most of the things that make Squeak
> > >such a productive system for developers.  We have moved away from the
> > >concept of an exquisite personal computing environment to something much
> > >more rigid and prescriptive.  This may put people off adopting such an
> > >approach, but I think stability and flexibility are mutually exclusive
> > > goals.
> > >
> > >-- conclusion --
> > >
> > >Due to Squeak's origin as a personal computing environment, it has never
> > >had a way of allowing a large group of developers to work on it and re-use
> > >each others' artifacts.  Current efforts are attempting to change that,
> > >but there is no appetite for throwing the image away and starting again
> > >with a small core - a very hard task, made harder by the fact that all the
> > >development tools are in-image and need a larger core.  So the
> > >architecture of Smalltalk itself is against us.  Newcomers come in,
> > >realise that they can change the world in Squeak, do so, and then get
> > >discouraged when their code no longer works in the next minor version.  So
> > >they put Squeak away - nice toy, unsuitable for me - and go back to perl,
> > >or Java, or .Net, or something that has a stable core and where their code
> > >won't break in the next minor revision.  And it takes them more effort to
> > >develop in that environment, but *much* less effort to maintain.
> > >
> > >I admire Craig Latta's work on small images that do not contain a
> > >development system.  If we are ever to build a Squeak that allows many
> > >developers to work in parallel, Craig's work - or something very similar -
> > >is going to be pivotal, as the *only* way to build and test the core parts
> > >of such a system.
> > >
> > >I'll leave you with one last puzzle: why does majorShrink exist?  Why
> > >isn't it majorGrow?
> > >
> > >                 - Peter


-- 

Trygve Reenskaug      mailto: trygver <at> ifi.uio.no
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway