From jecel at merlintec.com Tue Apr 5 13:36:19 2005 From: jecel at merlintec.com (Jecel Assumpcao Jr) Date: Wed Jul 19 10:23:23 2006 Subject: partitioning strategy Message-ID: 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 From Dan at SqueakLand.org Wed Apr 6 15:24:21 2005 From: Dan at SqueakLand.org (Dan Ingalls) Date: Wed Jul 19 10:23:23 2006 Subject: partitioning strategy In-Reply-To: <200504051959.j35JwjLM029844@squeakland.org> References: <200504051959.j35JwjLM029844@squeakland.org> Message-ID: >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 From bergel at iam.unibe.ch Wed Apr 6 17:42:13 2005 From: bergel at iam.unibe.ch (Alexandre Bergel) Date: Wed Jul 19 10:23:23 2006 Subject: partitioning strategy In-Reply-To: <20050405193547.D4BAC1502B@mailhub03.unibe.ch> References: <20050405193547.D4BAC1502B@mailhub03.unibe.ch> Message-ID: <20050406174213.GA1203@iam.unibe.ch> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From ducasse at iam.unibe.ch Wed Apr 6 18:10:15 2005 From: ducasse at iam.unibe.ch (=?ISO-8859-1?Q?st=E9phane_ducasse?=) Date: Wed Jul 19 10:23:23 2006 Subject: partitioning strategy In-Reply-To: References: <200504051959.j35JwjLM029844@squeakland.org> Message-ID: <5f8d23dc7adf40c431365624def05f5b@iam.unibe.ch> 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 > From jecel at merlintec.com Wed Apr 6 17:05:50 2005 From: jecel at merlintec.com (Jecel Assumpcao Jr) Date: Wed Jul 19 10:23:23 2006 Subject: concept names (was: partitioning strategy) In-Reply-To: <20050406174213.GA1203@iam.unibe.ch> References: <20050405193547.D4BAC1502B@mailhub03.unibe.ch> <20050406174213.GA1203@iam.unibe.ch> Message-ID: Alexandre Bergel wrote on Wed, 6 Apr 2005 19:42:13 +0200 > What are the difference between what you're doing and Spoon? My system is much more static than Spoon - more like ImageSegments. It might be interesting to contrast in more detail a system like this, Spoon (which is like two machines with partial connectivity syncing up) and TeaTime (which is like a set of tightly coupled machines permanently in sync). > 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... I normally use the term "object groups" but in the context of this list it seemed that "modules" might make more sense. -- Jecel