partitioning strategy

[Dan Ingalls]

>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.

Hi, Jecel -

No, the discussion is not over by any means, but I don't blame you for thinking so.  I have been remiss in not following up with some  next steps.

I have been held back by trying to do everything in one move, and now I'm feeling it would be better to at least move forward with two projects.  The two I have in mind are one similar to Environments, but with a very small change to the VM to support extension methods (a bit like my former post, but simpler), and the other similar to Andreas's Islands, which I think is much closer to what you are talking about here.

I'm travelling today, but I will write more about this when I get home.
Thanks for rattling the cage.

	- Dan

>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