----- Original Message ----- From: "Les Tyrrell" tyrrell@iserve11.lis.uiuc.edu To: squeak-dev@lists.squeakfoundation.org; "Dan Ingalls" Dan@SqueakLand.org Cc: modsqueak@bluefish.se Sent: Sunday, August 19, 2001 5:07 PM Subject: Re: [modules] What should be the first step?
I have a message pending (I just need to type it) on why ChangeSets may not be the answer.
It's sort of how I started out with Oasis... I just wanted a place to dump code where I could look at it without it causing trouble for my image. Later on I made that into a place where I could compile the code, instantiate objects, and interact with them, without clobbering my image. Which sounds very straightforward- but nothing that I did in Oasis was easy to accomplish.
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. That was true, of course, an entirely reasonable assumption at the time. But that means that there are much bigger mountains to move ( forget about getting to do something as easy as climbing them ) than you may be thinking. To give an example- In Oasis, I can load the entire class library for VisualWorks into a single module. There you have all the code in one module, just like it wanted to be. But... you can't use it, because you can't initialize this class library- over 200 classes need to be initialized, but the code to do it trips over itself... if I remember correctly, it went something like this: can't initialize Object, because Collections are initialized... can't do Collections, because something else isn't ready... Symbol and String are cyclicly dependent on each other, neither can proceed... The issues go deeper than just having some mechanisms like namespaces. "Just add namespaces" will not solve these problems.
As a counter-example, I *can* load a modified version of PocketSmalltalk's class library into a module, and I *can* instantiate and interact with objects defined by PocketST's classes. The reason is simple- I *can* initialize PocketSt's class library, because it was designed to be brought up from scratch. So, this is the route I would pursue, given that I already have Oasis- construct a class library similar to PocketSt's, but using Squeak's code ( I'd just use PocketSt's, but I don't believe it is open-source, though I could easily be wrong about that ).
All the PocketSt work is under an open-source license similar to the Apache license.
The benefit of such an approach is that I have a very clear picture of just what I havein the module, and whether it works. The hurdles I would have to overcome are that I would have to be able to generate Squeak's bytecodes, ( meaning that I might have to either port Squeak's parser and compiler to VisualWorks, since that is where Oasis lives these days, or run them on top of PocketSt inside Oasis, which I've explored a bit in the past ), and I would have to know how to generate a new Squeak image from scratch. Both of these things are justifiable extensions to the existing Oasis capabilities, as far as I'm concerned, so I'd be willing to give it a try if someone will tell me what I need to know about the image formats, and what the VM expects.
- les