On Thursday 15 May 2003 02:33, Stephane Ducasse wrote:
> I would like to have your point of view on the classBox.
> The paper has been accepted and we are including bench now.
> http://scgwiki.iam.unibe.ch:8080/SCG/559

One small correction: "but Us does not provide modules.", but Self does 
and Us is built on top of Self. Self's modules are based on set of 
individual slots, so they have the effect of global "class" extensions. 
When combined with perspectives in Us, you get the same functionality 
as ClassBoxes.

My impression is that the selector tinkering that Anthony is proposing 
for Squid is pretty close to your work.

The "class imports" vs "classBox imports" is what I was talking about 
previously in this thread. That latter is like * in Java, I suppose. 
That creates implicit dependencies and things may break if the set of 
classes defined in a module changes. Of course, this would break "class 
imports" as well but then it would be easier for a tool to warn about 
this problem.

There are limitations compared to other systems, but they are not 
important:

 - you can't extend a class with instance variables (as in "roles"). But 
you can define a new subclass and then don't have to worry about the 
values for the new variables in existing instances.

 - no versions. But you can get the same effect by always creating new 
modules instead of changing existing ones. Then old code will point to 
the original version of the module (which should continue to work) 
until explicitly updated to point to the new one instead. Different 
modules can load different "versions" of a single module at the same 
time. This is the answer to running 2.3 code in a 3.6 image...

 - no instances. But Squeak already has projects and perhaps these 
combined with classBoxes can get the job done together.

My view is that this is a very important development and certainly a 
step in the right direction.

It might be interesting to compare 3.3 modules with classBoxes.

-- Jecel