partitioning strategy

[Alexandre Bergel]

Hi Jecel!

What are the difference between what you're doing and Spoon?
Also, I think that for the sake of a good marketing, giving another name than "module" for what you're doing would be a good move. Your notion of module is far from what people have usually in mind...

Regards,
Alexandre


On Tue, Apr 05, 2005 at 04:36:19PM +0300, Jecel Assumpcao Jr wrote:
> 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

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.