components versus classes

Richard Staehli rastaehli at mac.com
Mon May 3 18:47:57 UTC 2004


We have prototyped a simple component architecture in Squeak (see 
http:/www.simula.no:8888/QuA), but the current mechanism for loading 
component "blueprints" has problems.  Here is a motivating scenario:
1) Alice implements a class Chess for chess games and serializes this 
code to a "blueprint" that is stored with the name "ChessBlueprint".
2) Alice advertises "ChessBlueprint" as a blueprint for a factory 
(class) for chess games.
3) Bob needs a chess game and loads a chess game factory from 
"ChessBlueprint".

Here's my problem.  I use the following code to serialize aClass:
	| serialization |
	serialization := ReadWriteStream on: String new.
	serialization header; timeStamp.
	aClass fileOutOn: serialization moveSource: false toFile: 0.
	serialization trailer; reset.

Then I rewrite the code to replace the class name with a special token 
'QuATemplate'.  This allows us to fileIn the code without the risk that 
the class name will conflict with other user code.  When Bob loads the 
blueprint, the following code recreates the class:
	(ReadStream on: blueprint) fileInAnnouncing: 'loading ',aBlueprintName 
printString.
then the resulting 'QuATemplate' class is renamed to a unique name 
generated for the current image.

This mechanism is too complex, wastes time with rewriting and renaming, 
fills up the change set with lots of useless changes, and sometimes 
results in obsolete classes hanging around.  Anyone care to suggest a 
better approach, particularly if it is easy to implement in our 
prototype?  Since our component architecture must keep track of which 
components are active and support binding, we don't need Smalltalk to 
allocate a global name at all.  Ideally, we could create a read a class 
from a stream just like any other object, without assuming that it is a 
change to the code in the image.

Richard Staehli




More information about the Squeak-dev mailing list