Module and Method source

[Craig Latta]

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 at netjam.org
www.netjam.org
[|] Proceed for Truth!