>Dan Ingalls wrote:
>> 1.  Any outside pointer into a project interferes with the imageSegment mechanism.  Thus any global variables in a project (and this includes any classes right now) will not be included in the module that gets written.  This is not a problem for export/import, but it is a problem for module swapping.  This problem would be solved if there were another variable scope associated with projects.
>>
>> 2.  If an incoming project defines global variables, they may interfere with the bindings of the receiving system.  This, too would be solved with project-local variables.
>>
Edward P Luwish <eluwish at uswest.com> replied...
>There needs to be a better mechanism than a debug trap when a running module references a global or class defined in an unloaded project.  Ideally, the external project should be loaded the first time one of its variables is referenced by an active message.  This would require a core class for cataloging externally-defined variables by scanning the project files during image initialization (or on demand).  If there are two projects that are alternative implementations of the same feature set, and thus both define the same global symbols, they would have to either be loaded
>explicitly, or each contain one project-unique variable that is referenced before any other global.  What I am proposing is analogous to demand memory paging.  It should also be possible to swap out a project when not actively used, but it's too early in the morning for me to deal with it.  I will look at Dan's splendid design outline to see if a paging mechanism can be built around it.

Ed -

I agree that if we can handle a dangling reference, we should.  My point was only that it's non-fatal if we cannot.

Regarding demand paging, the current ImageSegment package actually does what you want here.  A package could be swapped out and would automatically be brought in upon the first reference to something stored in it.  We do this already for Projects, although without the added local name space.

	- Dan