Hello!
Now that you have modules (by the way, what is the definition taken of a module? A changeset with prerequisite?), I was wondering why not to include the responsability of source management in the module itself rather than in the method?
In that case, the 4 bytes trail would be avoided....
Alexandre
Hi Alexandre--
...why not include the responsibility of source management in the module itself rather than in the method? In that case, the 4-byte trailer would be avoided...
Indeed, I just haven't gotten to that yet. With all the other big changes going on, it's too soon. :) There's also the matter of the activation bit I added to the trailer, which I want to keep there. (When the virtual machine runs a method, it sets that bit. Later, one may see whether that method has been run, and swap it out if it hasn't, for example.) I wouldn't want to have do a lookup to get at that bit, and I didn't feel like putting it somewhere else (e.g., the method header), at least not until I'd lived with it for a while. At the moment, I feel the same way about the version bits I have in the trailer now, too. I guess the trailer is a bit of a grab bag for experimental features. :)
But yes, the source pointer would be the first thing I'd toss. It also begs the question of whether to get rid of source files, too. :)
...by the way, what is the definition taken of a module? A changeset with prerequisite?
No; currently a module is (among other things) a collection of method definitions and prerequisite modules. Method definitions cache information about compiled methods (behavior, selector, author, version, etc.; source pointer or source code would be a perfectly fine thing to store here, by the way). Method definitions also know how to write out method IDs (compact representations of that information suitable for transfer between systems on a network). Method IDs are used in the parameters of messages sent between local and remote modules when they synchronize.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
When I have implemented the Classboxes, I choosen to get rid of the changeSet, source file and blah blah. They are still there of course, but a classbox is self contain and does not depend on external file or whatever...
Thanks for your explanation, Alexandre
On Mon, Jan 19, 2004 at 11:28:56AM -0800, Craig Latta wrote:
Hi Alexandre--
...why not include the responsibility of source management in the module itself rather than in the method? In that case, the 4-byte trailer would be avoided...
Indeed, I just haven't gotten to that yet. With all the other big changes going on, it's too soon. :) There's also the matter of the activation bit I added to the trailer, which I want to keep there. (When the virtual machine runs a method, it sets that bit. Later, one may see whether that method has been run, and swap it out if it hasn't, for example.) I wouldn't want to have do a lookup to get at that bit, and I didn't feel like putting it somewhere else (e.g., the method header), at least not until I'd lived with it for a while. At the moment, I feel the same way about the version bits I have in the trailer now, too. I guess the trailer is a bit of a grab bag for experimental features. :)
But yes, the source pointer would be the first thing I'd toss. It also begs the question of whether to get rid of source files, too. :)
...by the way, what is the definition taken of a module? A changeset with prerequisite?
No; currently a module is (among other things) a collection of method definitions and prerequisite modules. Method definitions cache information about compiled methods (behavior, selector, author, version, etc.; source pointer or source code would be a perfectly fine thing to store here, by the way). Method definitions also know how to write out method IDs (compact representations of that information suitable for transfer between systems on a network). Method IDs are used in the parameters of messages sent between local and remote modules when they synchronize.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Squat mailing list Squat@netjam.org http://netjam.org/mailman/listinfo/squat_netjam.org
spoon@lists.squeakfoundation.org
-
Alexandre Bergel -
Craig Latta