Hannes Hirzel <hirzel at spw.unizh.ch> wrote:
> Thank you for your interesting write-up. Would it be possible to add a
> section where you contrast the layers you are talking about with the image
> segments currently implemented in Squeak. Which features do remain
> unchanged which features are new?

In the current image, "image segment" may refer to two things:
 A. a graph of objects reachable from a set of roots that are not
reachable from anywhere else with pointers to outside objects converted
to pointers to elements in an outPointers array, or
 B. an ImageSegment object that contains A above, plus the outside
objects that the out pointers referred to originally so they can be
converted back when reloaded.

B can be saved to disk as an internal segment or an exported segment. 
If it is saved as an internal segment than the ImageSegment object is
kept in memory while its A part is written to disk.  When it is brought
back into memory its out pointers are mapped to the outside objects kept
in the associated ImageSegment object.  However, if an ImageSegment is
saved as an exported segment than the outside objects that the out
pointers refer to must also be saved.  They are saved using
SmartRefStream, not image segments.  So an exported segment is a
combination of image segment and serialized object stream.

My layers would just use the A version of image segments.  Out pointers
would refer to objects in parent layers.  In addition I would eliminate
the roots array effectively making every object in the segment a root.

> A point which I see immediately is that a layer like you propose knows its
> prerequisite layer while an image segment does not.

Correct, a layer isn't a substitute for image segments, it uses image
segments as described above.  A layer consists of: pointers to parent
layers, an image segment, and a set of changes (Smalltalk expressions).

> It would as well be nice to see how this goes with the work Henrik
> Gedenryd is doing at the moment. As far as I understand are the modules he
> is doing are class categories (UML sense) given real value. 
> The focus is on code loading and unloading. 
> Your thoughts seem to be at the more concerned with loading object instances 
> in a database sense as well.
> I do not see how this relates yet besides that you are working more on an
> binary / object pointer level.

Exactly, which I think is a benefit because layers can be used to
load/change any type of object not just code objects (classes, methods,
etc).  New classes that a module loads would be put into a layer's image
segment.  Classes that a module changes (DeltaModules) would be
expressed in the layer's set of changes.
	The benefit of loading/changing at the object level is apparent when we
look at loading components like morphic projects.  Morphic projects are
currently loaded using version B ImageSegments which is less efficient
and more complicated because of it use of SmartRefStreams.  The
SmartRefStream has to use ad hoc ways to bind globals objects such as
classes to the appropriate class object in the importing image.  Using
persistent unique immutable layers, class pointers will always point to
the correct class, and will know how to get the correct class if not
already in the importing image.

> Thank you for the analysis work you are doing and for communicating your
> ideas.

Your welcome, and thank you for your response.  The more feedback I get
now the quicker my implementation will be, since it will help reduce the
number of redesign I will have to do once I start coding.

Cheers,
Anthony