Les,

The only logic I don't follow is why you think the module reference needs 
to be physically contained in the class or CompiledMethod object.

Wouldn't it be easier to have a parallel structure that recorded for each 
class or method, it's defining module. To save space, at the method level 
this could be an exception table. A method is assumed to be defined by the 
same module as its class, unless a different module is explicitly listed 
for it.  Also, it should be easier to deal with global variable and other 
edge artifacts using a scheme like this.

There are lots of good reasons for this separation. First, it separates the 
essential runtime meta structures that are required by the virtual machine 
from the development/management meta data that may only be needed by 
development tools.  This makes life much easier for people who want to 
generate minimal-size application deployment images that don't need any 
development support.

Another advantage of such separation is that, in theory, you could define 
multiple modular views upon the same image.  This might be quite 
interesting during the phase when people are experimenting with alternative 
ways to modularize the system.

Finally, this type of independent representation of the structure of the 
image is essentially the basis of the "semantic model" used by ModSqueak, 
Team/V, and other similar systems.  Once you take a little step in that 
direction, its easy to take additional steps and do a lot of neat things.

Allen











At 10:40 PM 8/23/2001 -0700, Les Tyrrell wrote:
>The last few weeks we've seen a tremendous amount of discussion on 
>bringing modularity to Squeak, and I know that some of you are really 
>itching to get on with the show.  The last few weeks I've been dusting off 
>a few things, reconsidering others, and generally getting back into the 
>swing of things.  I've thrown out a few cautions, but hopefully these are 
>not overly pessimistic.  The inventory of working code waiting just 
>offstage is actually rather impressive, and I'm not just tooting my own 
>horn here ( the same would be true if none of my stuff had ever been built 
>).  I wish I were in a position to throw out Oasis to the masses and say 
>"here's your answer, live long and prosper!", but that won't happen for a 
>while yet- I still have some things to explore there before I'll have time 
>to release it.  So, out of practical concerns, I'm basically limited to 
>making a few comments here and there.
>
>The last couple of days I've been pondering how to move Squeak forward, 
>but perhaps without getting bogged down in some of the potholes that I've 
>encountered while building Oasis.   Bear in mind that I am not claiming 
>that there are any quick and easy shortcuts- I shall judiciously avoid 
>using the word "just", for instance- I've come to really find that word to 
>be annoying.
>
>In the early stages, it will not much matter how you build modules, or 
>what characteristics they have.  If you have *some* kind of module system, 
>the code it handles can be transferred to a different module system at a 
>later date when the issues are better understood and you can see where the 
>deficiencies really lie, not just where you anticipate them lying.
>
>What *does* matter is to begin seeing what is going on when you try to 
>herd all those cats into a nice orderly modular world.  And it would be 
>very helpful if you were cut a bit of slack in the early stages.  A lot of 
>slack would be better.  In particular, I've been thinking that it might be 
>useful if you were to go ahead and introduce modules now, but in a fashion 
>where they are more or less just decorations.  That is, go ahead and use 
>the existing environment variable on the classes to point to bona-fide 
>modules in whatever scheme you pick.  But don't let it mean too much just 
>yet- the classes would still be reachable through the Old Reliable means 
>of the SystemDictionary Smalltalk, and your existing code tools would work 
>no differently than before.  Think of the module system as being no more 
>valuable to you than a thin layer of paint- don't get too attached to it 
>just yet.  But go ahead and build new tools that use it, tools that 
>realize that the older non-modular tools may do things behind their back.
>
>I have several reasons for suggesting this.  One, obviously, is that it 
>would be nice to try out different modularity schemes over time.  But that 
>isn't the most important reason at all.  Easily the most important ( well 
>it comes to mind quickly in the middle of the night, at any rate ) is to 
>avoid the Class Initialization Problem.   You don't want to tackle this 
>yet.  It will have to be handled, but not today.  Example: in Oasis I can 
>and do load the entire class libraries of many different Smalltalk 
>dialects.  But to no avail- you can't initialize them because they are way 
>too deeply non-modular.  Just can't get there from zero, or so it seems, 
>certainly not without some doing some pretty fancy stuff, or just 
>accepting the fact that you have to start with a completely new class 
>library.  If I could, then I could run into the next problem on the list, 
>which is along the lines of "What to do about nil?" and so forth.  But 
>Allen says I can get around that, so I won't worry about that for now. ( 
>actually, I can get around this by using PocketSt, but that's not my point ).
>
>If you side-step the CIP, you can have modules as soon as you define class 
>Module in your likeness.  The first thing you will notice is that there 
>certainly are an awful lot of methods out there that your modules are 
>providing for classes that they don't define.  So this brings me to a 
>second suggestion- just as we have an environment variable for classes ( 
>and rightly so, AFAIK ), if we add an environment variable to 
>CompiledMethods ( or a subclass which can be used by recompiling all 
>methods in the system ) then you have a mechanism to keep track of which 
>methods in a given class are "native", and which ones are really there 
>because some other module wanted them there.  This would be a crutch- I am 
>not seriously suggesting this as a long term solution.  Perhaps it is, but 
>I don't have any insight to that at this stage.  But if you did this, and 
>had the tools to help you discern whether a given method belonged to the 
>module in which its class is defined, or should instead be listed as an 
>extension method provided by another module, I think you could get rolling 
>relatively quickly.  You would have to be tolerant of the Old Reliable 
>tools creating these new CompiledMethods without giving them a reference 
>to a module, but that would be easy to accomodate with the new tools.
>
>So, I guess what I'm proposing for this early stage of the game is a form 
>of weak modularity, hopefully one that can grow gracefully into a strong 
>modularity.  I'll give it some more thought, and will try to give this a 
>try both in Squeak and in my Oasis development image to see how well it 
>works sometime this weekend.  (These things almost never work so easily)
>
>Take care!
>
>- les
>
>
>
>