Igor-

Thanks for the feedback. I'll look more into what Mike is doing with
SecureSqueak.

Your thoughts also help me clarify something for myself as to VMs. I realize
now that I am mosly concerned with writing out sets of code and objects
(like in PataPata) whether they are called "image segments", "modules",
"parcels", or whatever, as opposed to writing out images.

And much of this issue of globals for me revolves around how to make it
possible to track what objects go in what image segment (or module or
whatever). And when an object is created is the most obvious time to make
that assignment to an segment/module/parcel/whatever.

I'll agree good tool support for this whole process is essential. For
example, if you were using an inspector, you may often want to know what
module the object was supposed to belong with (or even what image if it was
browsed remotely like with Spoon), as well as maybe change that
relationship. This is probably true as well for loading multiple version of
the same class into the same image (assuming you wanted to write the class
and its instances back out later). And this class/instance relationships is
another way to keep objects separated into modules or some classes of
objects But ultimately, if I write out a live window along with the class
which defines it, I need to write out all the mall integers or collections
which define the window and its behavior and state as well, and those
instances of core classes will usually be defined elsewhere. As I wrote here:
  http://patapata.sourceforge.net/critique.html
there were many disappointments with PataPata, but the small text based
images were something I was pleased with (like the 4K example I linked to
which defines a live window). See also:
  "Power Of Plain Text"
  http://www.c2.com/cgi/wiki/quickDiff?PowerOfPlainText

Anyway, I see as a matter of emphasis what I should be focusing on in a
Squeak/JVM is indeed good tool support as well as whatever it takes within
the underlying infrastructure to be able to round up objects and say they
belong together in some package to be written out. And naturally, the
objects might want to know what module they belong to too, if they need to
use that information someway (like module specific globals).

--Paul Fernhout

Igor Stasenko wrote:
> I'll try to be short.
> 1. No, smalltalk VM (at least  squeak) doesn't care about globals (in
> most cases). It uses a special objects table, which can be replaced on
> the fly.
> It simply because VM don't need to access globals when doing method
> lookup. All objects refer to its classes directly.
> 
> 2. To get rid of globals you have to change only few lines in compiler
> code :) Of course, you should provide something another in exchange.
> Btw, if you search mail archives, you'll find a discussion about that.
> 
> 3. The main barrier in making multiple versions of same class/package
> to live is support of  dev tools (browser/compiler). VM don't require
> groundbreaking changes to support this.
> The exception is tagged oops (smallintegers) and well known
> singletons: nil/true/false objects.  Even if you will have multiple
> SmallInteger classes, instances will be able to use only one of them.
> This is a sacrifice.. Well, but you can always make boxed integers :)
> 
> 2 Paul: most of these ideas can find a way into world, when Michael
> van der Gulik will release his SecureSqueak project.
> So, i suggest, you better discuss details with him in first place,
> since he is the most interested person in this area. My idea of having
> multiple versions of packages was just a fruit of discussion with him
> :)
> Also, i noticed that Mike's view on many things in different areas are
> very similar to mine, which is good :) Who knows, maybe we'll join our
> efforts someday.