On Wednesday 02 March 2005 3:37 am, goran.krampe@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.
packages@lists.squeakfoundation.org