[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
|