On Wednesday 02 March 2005 3:37 am, goran.krampe(a)bluefish.se wrote:
> - Colin supports Alan Lovejoys definition of "separately deployable
> code" (well, not "objects" perhaps). I do too. We should "choose" what a
> "module" is, and that is IMHO the overshadowingly most important
> attribute of it. Though "objects" is a better word than "code".
Yes. I think an important but perhaps overlooked point here is that we seem to
be making the distinction already between 'code' and other objects. Perhaps
this is one of the distinctions between a "distributable package" and a
"deployed module". Currently, of course, when we load a package we compile
source code into the image. So we could look at the source code that's in a
distributed package as either:
(1) a kind of inefficient serialization format (with the side-effect of
holding comments) for certain kinds of objects like:
- Classes and metaclasses, either new or modified
- CompiledMethod instances that get stuck in method dictionaries somewhere
- chunks of loose code that get executed on-the-fly or saved somewhere as
blocks (we could think of these as objects that get created and saved for
later execution, even though "later" is often pretty soon after their
creation.
or
(2) a special kind of non-object thing that gets treated different from "real"
objects.
I think it's important to remember that deploying modules more generally means
managing objects, *not* particularly compiling code. We know that we
generally have other kinds of objects to deal with anyway when we're
deploying modules (look at ImageSegments or Projects, or some of the
preamble/postscript magic in change sets that could otherwise be done by
holding pre-built objects).
I think that source code isn't (or shouldn't be) particularly important to the
modules project, while it might be to the packages project.
--
Ned Konz
http://bike-nomad.com/squeak/
