partitioning strategy

[stéphane ducasse]

Hi dan

Normally we had in the pipeline the removal of Environments as a 
subclass of SystemDictionary and the introduction of
namespace. So I would like to know if what you plan to do would work 
with namespace because this would let us clean
SystemDictionary as planned.

Stef

On 6 avr. 05, at 17:24, Dan Ingalls 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.
>
> 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
>