[self-interest] Re: Clustering in Self ?

[Jecel Assumpcao Jr.]

José Baltasar García Perez-Schofield wrote:
> 	I do apologise because of interrupt this "low-level, implementation"
> discussion, but I have a philosphycal question about Self.
> 	The matter is that Self can be considered a persistent language since
> it has its objects "living" in the Self world among executions of the
> Self environment.
> 	In many persistent languages, clustering techniques are applied to the
> persistent store (the world in Self), grouping together objects that are
> close one each other.
> 	(1) For example, "close" can be defined in terms of inheritance
> relations, or in terms of objects pointed by another objects ... or even
> combinations of this two considerations.
> 
> 	The question is: does Self follow any of this techniques ?

There are currently two views of a Self world on disk:

        A) a single large binary file called the Snapshot that is essentially a
memory dump of a running system

        B) a set of text files which are managed by a program called "the
transporter"

There is no clustering in A, while in B you explicitly group together objects
or slots into named "modules". There is a second level of organization in this
case since modules can include submodules.

I have worked on alternative designs which would divide the binary Snapshot
into several "clusters". The Squeak people have just introduced "image
segments" into their system.

> 	The central matter of the question is that, as far as I know, hte
> minimal unit of storage in Self is the slot, so, apparently, the "object
> semantic", is lost.

That is the case for the transporter. But for a Snapshot (either the current
monolithic one or one made up of small clusters) you would not be able to split
an object into anything smaller.

Before Self 4.0, programming was done by typing expressions directly at the
prompt or into files using any text editor. You would then load these files to
create or change the objects. Like the FileIns in Smalltalk, different files
could make changes to the same objects. So you tended to group in a single file
all of the changes (adding slots, mostly) related to a single project. You
might need to add a method 'isPrime' to 'traits integer' to make your project
work, for example. Then there would be one slot (namely 'isPrime') that would
not be found in the 'integer.self' source file as you would expect but in the
'myProject.self' file instead. Note that this is not unique to Self - Smalltalk
has always been like this.

When Dave created the transporter, he wanted to support this "tradition". So
you can tag different slots in a single objects as belonging to different
modules (and so as being saved to different text files).

> 	Are the slots of the same object grouped together, for example ?

Even in the transporter, the default is to make all slots in an object belong
to a single module. But they don't have to be grouped together.

In a system that stores *live* objects to disk (which the text file
representations mostly certainly are not, no matter how hard they try to fake
it) then objects must be the smallest grouping unit. This creates some hard
problems in terms of the work of different programmers combining in a usefull
way, but I don't see any way to avoid them.

On a related issue, you might find the work on "object grouping" at page fault
time that the Mushroom people (including Mario Wolczko - see his pages about it
at http://www.sun.com/research/people/mario/mushroom/index.html) very
interesting.

I hope this helps,
-- Jecel