A bunch of observations

[Ned Konz]

On Wednesday 02 March 2005 3:37 am, goran.krampe at 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/