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.