[modules] What should be the first step?

Les Tyrrell tyrrell at canis.uiuc.edu
Tue Aug 21 00:00:06 UTC 2001


From: Andreas Raab <Andreas.Raab at gmx.de>

 > > What I found as I built Oasis was that there were very
 > > deep-seated non-modularities permeating everything.
 > > It's not just the tools, or even the code, but perhaps even
 > > more significantly, the attitude.  Everything
 > > *knows* that there is only one namespace.
 >
 > To what extent is this related to change sets?! I've seen more than a few
 > apps that were shipped in the form of change sets and a number of them does
 > have multiple CS to prevent the kind of problems you're mentioning. So it
 > seems to me that what you're saying is that the equation module/component ==
 > 1 change set is not right - but I don't see anything in your post that would
 > render the use of change sets generally questionable.

In the near term, for the immediate task at hand, it may not be a great issue. 
You are not likely to be terribly concerned at this point with the core classes, 
where class initialization is a serious problem if you are trying to bring this 
up from scratch.  I don't think that class initialization will be as serious a 
problem for the non-core classes in the packages you are interested in.

If I understand correctly what is being proposed by the Changesets as Packages 
idea, is that existing chunks of code for which there are already changesets ( 
and therefore some mechanism of keeping track of all of the individual pieces of 
that chunk of code ) would be used as the definition of a package of 
functionality.  That's fine as far as it goes... but it will not go very far. 
It will work fine as long as you don't have to worry about overlapping method or 
class definitions.   Once that happens, it will not be enough.  What you need to 
consider is the probability that two different packages are going to conflict, 
and what will be neccessary to resolve that conflict.

You will find that in the general case the probability is somewhat higher than 
you would like.  You will also find that in the general case, the effort to 
resolve a given conflict can also turn out to be somewhat higher than you like. 
Method definition conflicts are very common, class definition conflicts less 
common but nonetheless more frequent than you would like. It would be nice if we 
could count on improved programmer discipline to avoid these problems, but I 
wouldn't bank on that.

Basically, rather than considering the case where you have an image with only a 
handful of packages loaded, consider the case where you wish to be able to 
quickly load, use, and unload many times that number of packages as quickly and 
effortlessly as possible.  You do not want to be tripped up by bad loads, or the 
inability to unload, or problems with conflicting definitions for methods or ( 
especially ) classes.  You want things to proceed as seamlessly and effortlessly 
as possible, with the least intervention required on the part of the user.

You need to allow conflicting definitions to exist simultaneously- Collage's 
Layers are one such mechanism, where in specificatoin space you might have more 
than one definition in the image for a class or method, but only one is chosen 
to actually be active in the image.  If neccessary, you provide a third 
definition that resolves the conflict, and that is the one chosen to be active 
in the image. Another mechanism to allow this would be to have strongly isolated 
environments, such as those in Oasis.  There you could have two conflicting 
definitions of a method , with *both* active in the image, with no need for a 
third definition that would attempt to resolve the conflict, because the 
conflict would not exist in the operational sense- although they would appear to 
have the same selector, in actual fact the selectors are different objects, and 
therefore indexed separately.  The behavior expected by each provider is the 
behavior seen by that provider, and no other. ( or so we think... I'll state 
that more strongly when I have a chance to actually test this... there are many 
things that I am working on right now ).

So, what I am basically saying is that looking at ChangeSets as package 
definitions is not a bad first step.  But I do not think it will take you very 
far before you realize that other steps are needed... which of course is 
entirely acceptable, since this is most likely going to be an interesting 
learning experience for everyone involved.

- les





More information about the Squeak-dev mailing list