On Reuse
Marcel Weiher
marcel at system.de
Thu Jul 1 15:26:39 UTC 1999
The image "melting pot" approach is one of the problems with reuse.
One part of reusing a component is to know what *requirements* the
component makes on its environment. Because of the image model, the
environment of any piece of code is the entire image used by the
code's author, so the only safe assumption is that everything needs
to be exactly the same. The actual requirements will usually be
less, but figuring this out is not an easy task (right Les?).
The other part of reuse is actually *using* the component. One
essential aspect of this is the "packaging" of the functionality, an
aspect that is often neglected. The Trampoline is an (extremely
simple!) example of packaging. It doesn't add any new capability, it
just provides packaging to existing functionality that makes it that
much easier to use.
In short, component encapsulation instead of (or rather in addition
to) class encpasulation. There is no need to lose the efficiency of
image-based development on the way: an image references various
components, changes are made to the image, leaving the components "as
is". The changes are pushed out to the components in batches, with
each such batch-change incrementing at least a minor version number.
The result is two-tiered code evolution model: quick image based
class/object evolution, and slower component evolution.
Marcel
> From: Peter Crowther <Peter.Crowther at IT-IQ.com>
>
> I contend that Smalltalks aren't like that. One Smalltalk image is a
> melting pot containing a large number of smaller products. Code
duplication
> that would be acceptable in two different products that would
never see each
> other is now less acceptable as the two products may well co-exist
in the
> same image, with different (and occasionally highly incompatible)
> implementations of the same idea. What happens if I have built a
product
> based on one set of event code, you have built a product based on
another
> set of event code, and a third party wishes to use both our whizzy
products
> in the same image? Do the two event models end up fighting for
keyboard and
> mouse events from the OS? Or are the code changes for the two
event models
> are so incompatible that they cannot even be compiled into the same VM?
> Lack of re-use isn't always harmless.
More information about the Squeak-dev
mailing list
|