[modules] What should be the first step?

Stefan Matthias Aust sma at 3plus4.de
Sun Aug 19 09:17:34 UTC 2001


Hi!

At 11:24 18.08.01 -0700, Dan Ingalls wrote:
>What does this say about our architecture for modules?

I'd like to add my opinion on this topic.  I'm sorry, if these points were 
already discussed.  Dan's suggested modularization makes sense.  Taking 
Allan's posting "Component's or Modules" in account, I'd prefer a 
component-based approach because that's more dynamic and IMHO better suited 
for Squeak.

So I'd suggest that there's a tiny core which manages 
components.  Components, in my definition, are self-describing (fully 
reflective) units of code which expose behavior via one or more 
interfaces.  The core can load and unload the components (either by 
filing-in or removing change sets or by some different approach like image 
components, self-describing serialized objects etc - I don't know) and 
register them.  A Squeak system is now plugged together from different, 
often replaceable components.

Here's an example: The core should have some way to communicate with the 
user.  Let's call that a console.  It can print some text or read in some 
text.  There're at least three possible implementations for that behavior: 
Using the Squeak graphics, using the plattform console, or using something 
like a serial interface for Squeak systems without an OS.  All these 
components should support the same IConsole interface (it give it some 
name) and depending on which component is loaded, Squeak will behave 
differently.

Each object, which wants to use a component's service has to query for the 
supporting interface and should expect that this interface doesn't 
exist.  So somewhere in the core, some code should execute this

   Console := Components componentByInterface: IConsole

to get some previously registered component for console behavior.

Once an interface has been defined, it may not be changed anymore.  The 
only way to extend that interface is to create a new version, which must 
support all old services and of course the additonal services. If you 
request an interface, you should also ask for a certain version, otherwise 
you'd get the latest version and that might be not what you want.  I find 
it helpful for development, that a version number of 0 denotes, that an 
interface isn't stable yet so that the rule, it will not change, is not in 
effect yet.

For the beginning, components could be defined as simple change sets (which 
should be enhanced however to support automatic removal).  Based on this 
foundation, concepts for versioning the code, for requirements and storage 
can be developed.

However, I'd like to see the migration of Squeak into a component based 
architecture first.

Here are some suggestions for components

  Core (Object, Boolean, all base classes like Collections)
  Compiler (everything needed to compile text to bytecode)
  Browser Model (stuff like "senders")
  FileIO
  SocketIO
  MVCUI
  MorphicUI

but also smaller stuff like

  Console
  File Dialog
  Source code formatting

So everything, that might be replaced because of a different combination of 
modules, a full features morphic file dialog doesn't makes sense in a 
command-line-only system, should get a well defined pluggable interface.

Code modules are still needed, but this should IMHO be the second 
step.  Regarding name spaces, I'd delay that for the modules, having module 
name spaces instead.

bye
--
Stefan Matthias Aust  //  The essence of magick is simplicity





More information about the Squeak-dev mailing list