The low road to modularity
marcel at system.de
Sat Feb 13 15:23:47 UTC 1999
External vs. internal facilities
Interfaces to external facilities need not be in conflict with
providing comparable facilities in Squeak itself. For example, I
don't think there is a problem with interfacing to platform-provided
font-renderers, as long as the interface is compatible with the
Squeak-internal one. In fact, I am almost sure that Squeak-Central
would welcome such a move. The external interfaces can serve as
reference implementations and kick-start mechanisms, allowing a
Squeak implementation to be built by gradually replacing the external
Interfaces need not be identical, all that's needed is a common
base-level that provides plug-compatibility. Further features can
then be layered on top of that.
Simple module support
The problem with module support at this point is probably not a lack
of good ideas (seen plenty) and sensible requirements (ditto), but
more an incremental approach to those goals.
My suggestion would be to start with something minimal, something
that (a) can be implemented without changing existing semantics (b)
is a step in the right direction and (c) isn't too difficult.
One thing that came to my mind is a very, very simple implementation
of a modularization mechanism, the ability to integrate Squeak
classes/methods (no more!) into an image without actually copying the
stuff into the image (read-only, shared).
This could be accomplished by having cover class-objects that refer
back to a read-only part not part of the image and also to a normal
writable part (possibly empty) that is part of the image. Any
modifications made go to the writable part, which overrides the
read-only part. The pointer to the referenced read-only part would
probably have to be hidden from the garbage collector.
The system behaves exactly as it does now, changes are made to the
local image and override what is in the loaded modules, which are
themselves not modified. Once modifications to a module are well
established, a new module with those changes incorporated can be
The semantics of such a system would be similar to remote messaging
to a separate image, but with a fast local messaging implementation
and local override capability.
The similarity to remote messaging can be used to make a remote
interface simply a special case of a module where the code is not
locally available. Native interfaces could also use the 'module'
mechanism. In each case, the module could provide a custom messager
that communicates the message via IPC or uses C-style argument
passing with conversions.
More information about the Squeak-dev