[modules] Cutting the knot

ducasse stephane ducasse at iam.unibe.ch
Wed Sep 26 07:39:49 UTC 2001


Hi Dan, 

Good! I was thinking that at the end this what would happen anyway but I
played the game just to see. I should have bet with myself. I was discussing
with Andrew Black and we agreed that the real problem for nonSqC people is
that you have to update, understand the changes every times you want to
update your code or download code from somebody else. so modules or
packaging will help this process.

So now I would really like to see a small of the system decomposed in
modules and having dependencies and versions between them. I would like to
see how we can load/unload a system like Alice or the speech recognition and
be able to have different versions of Morph and different versions of Alice
just to see how this would work.

My idea is that we should in the near future be able to load SqC Squeak or
another one. 

So the important points of this email:
**************************************

Once we have module in place, the next steps are to put in place some
infrastructure at the code level:
- we should take the filelist of swt which support registration of the tools
(this is implementation of henrik I adapted a bit).

- we should have the same at the level of the ui for morph and mvc. this
would avoid to have morphic referenced from the compiler. Or have all these
horrible Smalltalk at: #Morph everywhere in the code. This is clearly the
sign that something is missing.

- I think that modules without a clean dependency structure will be just
lazzagna instead of spaghetti code ;)

I think that analysing the dependencies between the modules will be an
important occasion for squeak to be cleaned (removing gifReader reference
from Smalltalk, or things like that), In the same way roel told me that he
could not write a nice visitor on html tree to check web page because there
was a dialog popping up as error, so we have a dependency between socket and
UI ;(
 
    -  Can you tell us how you see the process, because I would like to
    participate?
        What I see is that you or a group of volunteers will have to do a
        first pass to fix the original structure of the dependency between
        modules checking why certain conceptually unrelated modules are
        related. Then or fixing them directly or making a list of things to
        be fixed. 

    - Is there a analysis support for doing that?
    because in Envy the system tell us (brutally) when a class refers to a
    non-visible class. and this is important to move things around and as
    squeak does not have a culture of explicit tests this may be a long task


Some other important points:
****************************
Then I just want to point some process issues about the module discussion. I
was waiting for saying that: I hope that we will leran for the next time but
I'm not even sure ;(

If you look at the way modules have been discussed this is not really
efficient: 
    - we had lot of traffic at the beginning hence nobody could really take
    the time to read everything. I tried and it was extremely difficult. So
    imagine somebody working full time and travelling receiving all these
    emails. -> put a moderator next time

    - we put the modsqueak too fast in the mailing list and got noise (sorry
    but do not touch my image emails were boring!) then

    - we excluded the people of the modsqueak mailing-list. Look at who
    really used this modsqueak  mailing-list. I think that this would have
    been clearer to say to them:  "you do not want to be in the mailing ok
    we will not interact with you."

    - I'm personally a bit frustrated because lot of the design points I
    asked have never been answered like if they were or stupid or misplaced.
    originally I was thinking ok I do not care, but I care because I'm
    investing on Squeak. So I hope we will not realize mistakes in 1 year
    from now.


Stef


> -- 
> Folks -
> 
> I feel the need to cut what has become a Gordian knot.
> 
> By the end of this week I intend to issue Henrik's module code as updates to
> Squeak 3.1alpha.  While this may look selfish or irrational, I think it's the
> right thing to do, and at this point someone will likely be unhappy no matter
> what we do.
> 
> Our top priorities for modules in Squeak are:
> 
> Support modularity of active Squeak content
> distributed as projects on the Internet
> 
> Support an ecology of interrelated enhancements
> to Squeak from throughout the community
> 
> Keep it small and simple.
> 
> This is a Squeak Central perspective.  Others surely have other priorities.
> We feel that as soon as we achieve the first goal, Squeak will disappear.  In
> other words, the significance of Squeak as a vehicle for easily-authored
> multimedia content will dwarf that of Squeak as a development environment, and
> all the activity of this mailing list will likely pale by comparison to work
> on active content.
> 
> The ModSqueak work is an excellent system with a somewhat different set of
> priorities.  It could be made to serve these ends, but I foresee constant
> conflict in trying to do so.  I prefer to proceed directly toward these goals
> with Henrik's code, and to allow the ModSqueak facilities to remain one of the
> packages that can be easily loaded by anyone who wants its particular
> benefits.
> 
> In adopting this approach we will take care that nothing in the resident
> module scheme interferes with loading and using ModSqueak as now.  Presumably
> a great deal could actually be shared, once the dust settles a bit, and
> loading should, of course, become simpler.  What is important is that
> ModSqueak can remain just what its authors intended it to be, and the the
> resident module system can be tweaked into a lean and effective architecture
> for community sharing and active media on the web.
> 
> Those who have followed the full modules discussion will recognize that our
> first priority here is really more of a component architecture, and this is
> true.  At the same time, we feel that the module kernel will serve well the
> needs of the Squeak community for collaboration and distribution of add-on
> packages, as well as producing reduced images for PDAs, servers and other
> applications.
> 
> Yours on behalf of SqC (and wearing asbestos today ;-)
> 
> - Dan
> 
> 





More information about the Squeak-dev mailing list