Subjective Squeak

Brent Vukmer bvukmer at blackboard.com
Wed Dec 11 19:59:51 UTC 2002


I see two parallel paths for layered programming environments, being
described on the list:

(A) multiple images built out of various permutations of packages
(B) a single image running multiple versions of a package in different
projects/namespaces

In approach (A), the infrastructure is:  shared repository ( a la
Monticello) + packages + load scripts + factored image.  In this
approach a Squeaker would build a fresh image to spec for each
combination of package releases that I want to explore.  ( Avi Bryant
has alluded to his use of an approach something like this in doing team
development. )  As the image shrinks and SqueakMap grows, and Monticello
becomes more and more robust, this approach seems like it will quickly
approach a very close approximation of the experience provided by (B). 

What could be done in (B) that couldn't be done at all in (A)?  Or in
what cases would (B) provide a more enjoyable/instructive experience for
people to build something in Squeak?


-----Original Message-----
From: Anthony Hannan [mailto:ajh18 at cornell.edu]
Sent: Wednesday, December 11, 2002 2:03 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Subjective Squeak

[snip]

You should read the Us paper.  Its at the site I gave, just click on PDF
in the upper right corner
(http://citeseer.nj.nec.com/smith96simple.html).  I agree AOP is
complex, but layers is implemented as just another lookup dimension. 
And from the programmer's/user's point of view it is just projects.  You
work in one project then maybe switch to another, any if there is
anything in common you want to share between the projects put
them in an inherited project.  The concept is the same as behavior
inheritance, but this is at a larger scale, call it image inheritance.


> > I really think layers will improve our package model in the
> > image, particularly with respect to dependencies, versions, and
> > unloading capabilities.
> 
> I think that we do not need that for that. Basic software engineering 
> principle and namespaces are enough for that. May be Layers could
> solve that but may be they are introducing another layer of complexity
> just at the cognitive level.

Layers (environments as I have described them on my website) are
dynamically bound namespaces and nothing more.  This allows you
to override them to change the behavior in different layers.  Thus
giving you multiple packages/projects that can be run and analyzed in
the same image.  Being able to work on different packages/projects in
the same image is important, and without something like layers it can't
be achieved.

> but may be they are introducing another layer of complexity just at
the



More information about the Squeak-dev mailing list