[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
|