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