On February 1, 2005 04:36 am, stéphane ducasse wrote:
> > yes! one note/question - do you think using Stef's (at all) Traits
> > would
>
> Nathanael's traits (I'm only responsible of the topic and aliases :)

my bad, sorry Nathanael i thought i was reading Stef's article on traits -)

> But yes this is the goal of traits.
>
> > 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