Modules for Squeak, was: (Re: [Newbie Q] COM, beans, and Squeak)

Edward P Luwish eluwish at uswest.com
Wed Jun 23 20:39:17 UTC 1999


One of the nicer features of QKS SmalltalkAgents, which could serve as a
model for work in Squeak, was the Namespace class.  This class allowed
for the creation of isolated classes and even the overriding of methods
in basic classes (like Object!) without causing disastrous side effects
in the overall system.  Only projects defined in a given Namespace would
see the classes or methods defined in the Namespace.  I am not sure
whether the mechanism was general enough to permit moving an existing
class into a different part of the class hierarchy, but I would not be
surprised if that were part of the deal.  The overall goal, I think, was
to create compatibility zones for ParcPlace, IBM and even Digitalk
fileins - I am not sure how much of this was ever implemented.  There was
also a facility for constructing loadable/unloadable bytecode modules,
and for shipping standalone applications by pruning off every class other
than those needed by the app and compiling the bytecodes into native
machine code (the virtual machine would therefore not have to be shipped
with the app).

Hmm.  This is at least the second time I mentioned this Smalltalk
implementation in this group.  The reason is that it was the only
commercial Smalltalk I ever bought, not that I have any particular bias
one way or the other.  At the time, it was the only product that 1) Ran
on my Mac; 2) Had a complete set of classes (Squeak didn't exist; gnu had
incomplete GUI support); 3) I could afford (I bought it cheap at
Macworld, but free would have been better).  All in all, though, it had a
lot of good features I have never seen anywhere else.  I don't even know
if it still exists.

Ed

Les Tyrrell wrote:

> There are a number of interested parties- my own approach,
> evolving as we speak, is partially described at:
>
> http://www.canis.uiuc.edu/~tyrrell/Squeak/Personal/Oasis/index.html
>
> The description is actually very sparse, I really need to update
> this.  Oasis, like most of what I do, is written for VisualWorks.
> However, it is not UI-dependent so I don't anticipate much difficulty
> in porting it to Squeak.  I'm close to finishing up one of the
> analysis tools in Oasis, so perhaps I can get something decent
> written about it in the near future- the current description
> of Oasis is very inadequate.  Basically, given some arbitrarily
> huge chunk of code, Oasis tears it apart and builds a number
> of useful analytical models that I can then browse ( but without
> a UI at this time ).





More information about the Squeak-dev mailing list