Steps to Modularity - Incremental Snapshots
Marcel Weiher
marcel at system.de
Tue Mar 16 09:43:29 UTC 1999
> It seems to me this would do a great job of storing unneeded
classes (they are
> mono-rooted trees) and projects or morphic worlds, or books.
....
> The third would write the binary patch to a file, leaving only
the file
> reference and outpointers behind. The third form works a lot like
a DLL.
Hi Dan,
I am really happy to see you tackling modularity. What I would like
to see is a way for putting frequently used but mostly static stuff
into Squeak shared libraries as well. These would have to be
explicitly loaded at startup, in order to avoid the problems with
direct VM references you pointed out for the auto-faulting scheme.
For each class in such a shared library / package, an
'external-class' class-object is created within the importing image
pointing to the CompiledMethods etc. stored externally. When the
importing image is saved, these external class proxies simply save
their package-reference. The 'system' pointer approach for accessing
globals should help avoid out-pointers.
The external class proxies could even support modifications that are
reflected only within the image but leave the imported package alone
+ the generation of a new package with those changes applied ('flush
changes to new package').
Somethng like this would help Squeak support light-weight scripting
tasks and the model of many different images, instead of a single
mega-image with stuff swapped in and out.
Marcel
More information about the Squeak-dev
mailing list
|