partitioning strategy

[Jecel Assumpcao Jr]

I don't know if the discussion here is pretty much over or not, but I
thought it might be interesting to mention a small detail about my
project.

Suppose that the system is already partitioned into many well defined
modules and that you are now just using it for daily tasks. How should
the stuff you do from now on get partitioned into separate modules?

My solution was to define two different kinds of #new methods. Sending
#newLocal to a class will create an object in the same module as the
sender, while #newRemote will create a brand new module with the new
object as its initial content. There is no way to directly create
objects inside existing modules besides your own, though of course you
can send a message to some object there and it can do #newLocal for you
if it wants.

In my system modules don't have names, so this scheme doesn't deal with
them.

The idea is that each different kind of object will implement #new
either in terms of #newLocal or #newRemote in such a way that just using
the system exactly as we do now nearly always does "the right thing".
Sending the more specialized messages allow us to override the default
in the rare cases where it isn't what we want.

So creating a new Tetris game might generate a new module to hold it,
while a new button created as part of the new game would go into that
same module.

This should be tied into the user interface, of course. Currently
Projects do this very well, but I would rather spread out my objects on
an infinite plain like in Self (with zooming it would be even better)
and then we lose the "everything on the screen = one module" relation,
which is why I came up with the scheme I described above.

-- Jecel