Uninstalled code

| Incidentally, there's no particular reason this needs to be so.  A good
| loader could synthesize an empty class whenever you load classes out of
| order.  This is basic "code blop"-level functionality.

The idea behind not loading a class if its superclass is missing and not loading a class extension unless its class is present is to allow the maintennance of "logical packages".

Imagine a graphical inspector package (GIP) built on something like HotDraw where we want to be able to add special renderers to specific classes of objects so that when they are displayed they are displayed as we would like. Imagine we first implement this in a monolithic Smalltalk system as a single loadable package.

Sometime later the monolithic system is decomposed into a core base system and a number of loadable components such that some of our special renderers now apply to those loadable components.

Typicall package systems would make it impossible to load the graphical inspector until all the relevant decomposed components had been loaded. In practice this might force the maintainer of the GIP to decompose it into a core component that matches the core base system and a number of fragments that correspond to each loadable component. If there existed any package that extended the GIP it too might have to be similarly decomposed.

Every time the system was decomposed the maintainers of packages would have to check for conflicts and decomose. This decomosition activity grows as the geometric product of the numer of components. It doesn't scale.

A further serious problem is that the package system is avoiding rsponsiblity for arranging that the relevant fragments get loaded apropriately. How does the system arrange that if the GIP core is loaded and then one of the components that can be extended by a GIP fragment gets loaded that the GIP fragment gets loaded? Tis is a responsbility that belongs in the package manager, not on the poor package maintainer.

Were one to synthesize classes to allow these extensions and subclasses to persist in the system one wuld be a) polluting the system with non-functional code (confusing people browsing teh system, tempting them to modify these classes, etc) and b) deferring conflict resolution problems to when the real version of the synthesized classes get loaded.

In the VW scheme the code that can;t be loaded is held by the package manager and not made part of the class hierarcy, hence invisible through the standard browser. This code is called "unnstalled code". Whenever a package is loaded the package manager examines the uninstalled code and installs that that can be installed.

With this facility the programmer/maintainer of the GIP can manage it as a single component (in VW's case a pair of binary parcel and source file) and not worry about decomposition of the system underneath their (sic) package.

Our experience with decomposing VisualWorks 3.0 was that this mechanism saved a huge amount of effort. The Digitalk folks working at DarcPlace-Dodgytalk when we did this told us that the Smalltalk Load Library scheme in VSE required decompostion and indeed resulted in a very exensive mainennance task in decomposing components and managing fragments.

Related are the need to support overrides, unloading, config maps, versioning and patches. But I'm not going to address these here.

| In general, I expect that load prereqs can be limited to kernel stuff
| like compilers.  Normal applications should never need them.  I hope...

That's simply not our experience. As the system gets richer, and especially asd people work in a less solitary environment where they aren't prepared to take ownership of components they depend upon (and hence won't perform the integration step that some people - typically very strong Smalltalkers - seem to think is an easy one) people require as much support in using loadable components as possible. That includes the ability for a package owner to specify the prereqs their (sic) package might need.
---
Eliot Miranda ,,,^..^,,,