Modules and class... [ a off-topic question ?]

Les Tyrrell tyrrell at iserve11.lis.uiuc.edu
Tue Feb 26 07:54:07 UTC 2002


----- Original Message ----- 
From: David Simmons <David.Simmons at smallscript.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, February 25, 2002 9:30 PM
Subject: RE: Modules and class... [ a off-topic question ?]

> Are these the kind of issues you've dealt with?

The issues I've dealt with most are strong isolation ( which *might* be considered one approach to sandboxing ), and deep analysis of static source code.  The other things you mention have already been handled by other systems, so I have not spent as much of my effort on them. For instance, ModSqueak would provide a very nice versioning/repository system that I should be able to integrate rather easily- until I see otherwise, no need for me to tackle that problem.

By strong isolation, I mean that I can bring code from many of the existing Smalltalk dialects, no matter how complete or incomplete, into an Oasis module ( which for most people would look most like a mini-Smalltalk environment ).  Roughly speaking, you could bring in such code with the methods first, then the class definitions, with the classes in reverse hierarchical order, and Oasis will dynamically adapt to that situation- undefined classes will be created to hold the methods and their instance variables until a definition for that class is given.  Unlike a regular file-in, I do not need to worry about what will be done to my image just because I wanted to look at some code.  However, to the greatest extent that is possible, the classes and methods that are in the module are active- that is, I can indeed instantiate them, and invoke methods on their instances.  They are not inert, nor simply declarative definitions to be applied only after the world is consistent.

As a result, Oasis is very able to deal with the sorts of file-ins you find lurking about in the older ST archives, or from prior iterations of the Squeak environment.  For instance, in one example I brought Pocket ST's core class library into an Oasis module, re-mapped its primitives to appropriate VW replacements, and then instantiated and invoked methods on the instances of those classes.  Couldn't inspect them ( they didn't understand inspect, and I didn't want to introduce a gui method to them ), but I could do some things with them.  In another case, I brought in the complete class libraries from several different dialects simultaneously- five of them, plus part of a sixth ( GNU Smalltalk does things that VW's vm will not support, thus I cannot bring it in actively, although the inert option is there as well ).

Implicit in this is that it would not take much effort to tailor each module to the specific needs of the classes it contains- ie, a module holding Squeak classes could have policies attached to it that automatically remap primitives, or handle that crazy {} syntax.  Objects instantiated from Squeak classes could interact directly with objects instantiated from Little Smalltalk classes - as long as they *behave* according to the same protocol.

I "modularized" the Refactoring tools, so that I can use the RB within my modules.  I've used it on itself this way, for instance- I can modify the tools without fear of clobbering the ones I am using to do the modification.  At one point, I dimly recall being able to grab chunks of code from one module and drop it into another via the RB.  I don't have that ability now, but from what I remember of this ( provided I am not merely dreaming that part up ) it should not be hard to resurrect.

Hmm... let's see what else is on the list.  Versioning. Pre-requisites.  I don't like this approach, so I've been exploring ways around it.  So, no- I don't do these sorts of things.  Versioning of individual code components is fine- nothing wrong with having a nice record available.  But I don't like imposing pre-requisites on them- this introduces explicit inter-module coupling, and what I would prefer to do is to find ways to encourage inter-module *de-* coupling.  So, I don't like forcing modules to be aware of other modules in any way- not through pre-req's, not through imports, and not through explicit out-of-module references.  Instead, I would prefer to find ways to build modules in a way that allows them to have the greatest reuse potential.  For instance, supose you have a chunk of code written in Squeak.  Just how dependent is it on Squeak's core that you really need to chain it to version so-and-so of Squeak.Core?  Perhaps not as much as you think... so have the tools to find out, and have the ability to go ahead and just drop it into an environment where you use a different core, such as Pocket St's or some other one you find lying about your hard drive.  Big deal if it isn't compatible- you have the tools to deal with it.  

Oasis has very powerful analytical capabilites- beyond the relatively trivial stuff such as being aware of methods that aren't implemented and variables that aren't declared, it is also able to extract from the source code very detailed information about the expectations held on all objects described in the source ( ie, everything for which there is an expression ), and from that extract interfaces, ie, the protocols that are being used between the objects in the code.  No fancy-smancy source code format is required- just plain old Smalltalk.  Capabilities like this give me good reason to believe that I can take advantage of such information when matching variables behaving in a class-like fashion in one module to a class which actually defines that protocol in another.  If nothing else, it certainly could be part of the puzzle, additional information that should prove useful to someone interested in resurrecting lost code ( this is behind most of what Oasis does ).  Even in cases where the dialect has disappeared - there is still a fair bit of a "shadow" left in the code archives of the things that used to be.  I can know the protocols of those things that were, and the things that they answered.  I can reasonably expect that the shadows can be reincarnated in a stubbed-out form - I have their names, I have the methods they were expected to understand, I know how the objects sent to them behaved, I know how the things they answered behaved.  I may even know what variables they were expected to have.

I don't worry too much about "schema changes", but if I did I am sure that I could reasonably expect to be able to handle them for things for which you have no explicit definition *at all*.  Which, of course, is a capability that takes considerably more effort to build than "version X of module A needs version Y of module B".  It's a research system- but even now, a fairly capable and powerful one.  Much work remains to be done, much has already been done.

Well, if folks like myself just mill about in the same old circles, I guess we won't find out will we?  You've taken one approach, I've taken another.  I still have great confidence in the approach I'm taking, just as you have great confidence in the approach you've taken, and others have confidence in the approaches that they have taken.  The more the merrier- no one of us is sufficiently brilliant to have covered all possible approaches, so I for one feel that there is more yet to be discovered.

Which, all in all, is merely a long-winded way of saying that I am indeed quite familiar with the fact that much of what you describe did not come easily.  I am well aware that chances are good that you have already been many of the places I've been in the past, and will be in the future.  But I am also reasonably certain that there remain many roads not yet taken.  I appreciate your taking the time to share your experiences, and look forward to hearing from you in the future.

- les

















More information about the Squeak-dev mailing list