[Squeakfoundation]An architecture for sustainable Squeaking

[Andreas Raab]

Henrik,

> And now hopefully we can get back to the issue I was
> intending to discuss with my posting.

Since nobody has commented on your original issue, I'll give it a try. I
need to say that as much as I agree with your general principles, as much I
must disagree with your concrete interpretation. In particular the first
principle saying

> (1) Architectural law: Modules may only depend on
> (use code in) modules "further in"/closer to the core.
> (Outward dependencies are forbidden.<*>

is a very good general principle but your interpretation of it in

> (*) This means no more "String asUrl", because this
>  makes the core module with String depend on the much
> less vital module PWS or whatever, so you have to load
> PWS to use strings.

is just utterly wrong. You could equally well declare that there must be
none of the "isXYZ" methods in Object. That effectively leads to the style
of using "((x isKindOf: Foo) or:[x isKindOf: Bar])" and that's most
certainly not the right way of dealing with the issue, is it?! So...

> _Maybe_ we need to allow outer layers to
> add code in inner-layer-classes, but this creates
> spurious sideways interactions between modules.

... my feeling is that the above should not read _maybe_ but _absolutely_.
Please note that there are no spurios interactions between modules as long
as long as methods are added and not modified and that adding methods can be
done in a perfectly safe way if selector name spaces are supported. In this
case PWS would - by using #asUrl - make itself a dependent of the URL module
(making #asUrl and the URL classes part of PWS itself defeats your own
interpretation of a layered architecture) the URL module would (by
implementing a method in String) be a dependent of the String (or Core)
module and everything follows nicely your general principle.

Similar things can be said about some other concrete interpretations you are
giving. Two examples are

> There is no longer any sharp line for what goes "into"
> Squeak here. This is very different from today's
> either-or-image situation.
... and ...
> There would need to be separate update streams for
> each module (and updating mechanisms would need to
> be provided by the system as well).

Neither do your general principles imply that there is no longer going to be
a sharp line nor do they imply separate update streams. Whether or not there
is a sharp lines depends on the distribution and inclusion mechanisms used
(meaning that there could very well be an extremely sharp line for various
things - just take the SWT image and check it out; a very sharp line can be
seen here cutting off every last bit of media related stuff in favour of
other things [this is no complaint, just an observation]) and the updates
could still come out of one source - all that is required is a dispatch
mechanism and whether this mechanism is on the client or the server side is
a completely independent issue.

So, I do agree with you on the terms of the general principles. But I can
hardly agree with your interpretaton in the concrete context.

Cheers,
  - Andreas