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