On January 31, 2005 10:21 am, Trygve Reenskaug wrote:
> 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.

Juicy bait, will stay atuned -)

Thanks for your comment, Milan

>
> 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