[Squeakfoundation]An architecture for sustainable Squeaking

Joseph Pelrine squeakfoundation@lists.squeakfoundation.org
Sat, 02 Jun 2001 16:40:45 +0200

Quoting you - ("Sorry, newcomer X, but your code's just too shaky, we'll=20
have to pass on that for now")

Please start by reading the numerous writings on modularity in Smalltalk=20
before posting things like this.

At 14:37 02.06.2001 , Henrik Gedenryd wrote:
>My idea is that we need a simple but powerful overall principle of
>(According to this proposal) we should adopt a variant of the well-known
>"layered" or "onion-skin" architecture, along with a principle that ensures
>(1) Architectural law: Modules may only depend on (use code in) modules
>"further in"/closer to the core. (Outward dependencies are forbidden.<*>
>Dependencies should be made explicit.)
>(2) Principle of sustainability: In a sustainable system, the more central=
>module is, the less volatile and more conservative it needs to be.
>That's all, technically, and these are not fascist laws but mere natural
>Obviously, closer to the core are more essential things. Outermost would be
>"applications" that are entirely optional.
>The further out, the more you can do what you want (because the less others
>depend on you), but also the more work for you to adapt to changes in the
>inner layers. (But these should also change less.)
>As code moves inwards, it gains importance, grows in value for others, but
>also takes on responsibilities.
>The closer to the core:
>- The more the quality, stability, etc. of Squeak depends on it (Squeak:=
>program, the community, all the uses of Squeak)
>- The more sensitive the contents
>- The slower should code change. Use maximum foresight. Not haque du jour.
>- The higher standards should be imposed on changes (bug fixes yes, good
>code a must, "good to have" additions & quick toss-ins nope, code that
>doesn't belong there--no way Jos=E9)
>- The more a module needs to be the "joint responsibility" of Squeak
>Outermost would be Applications, which:
>- literally noone else depends on
>- are free do whatever they wish,
>- but are the sole responsibility of their authors to maintain
>There is no longer any sharp line for what goes "into" Squeak here. This is
>very different from today's either-or-image situation.
>(*) 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. _Maybe_ we need to allow outer layers to
>add code in inner-layer-classes, but this creates spurious sideways
>interactions between modules. Perhaps only applications should be allowed=
>do this.
>Pieces like Celeste the mail reader app would most likely become
>multi-layered, with the UI outermost, and more generally useful code in
>separate, more inward layers--e.g. code for sending e-mail, which may be
>useful in many other contexts, notably for posting code to a list or so.
>There should be code that can validate that a (new) piece of code doesn't
>violate these rules, to automate things.
>There would need to be separate update streams for each module (and=
>mechanisms would need to be provided by the system as well). You choose
>which ones you want.
>Up to today if you want the essential bug fixes you will get SqC's latest
>experimental code tossed in for free. And if you opt not to be an alpha
>pilot then basically you won't benefit from the community any longer (in
>effect you do the f-word). This ain't a good situation.
>Note that many of SqC's experiments would become "far-out" layers (how
>appropriate). Or rather, SqC would need to divide their stuff into layers=
>well-behavedness too, if they want to contribute to the official system, so
>to speak. Otherwise the stuff would remain as applications.
>This will be extra work for them and I don't know if they will want to do
>that. It would make SqC have to play by the same rules as everyone else,
>essentially. This is the part that I have been uncertain about whether it
>will happen, but I think this is necessary. We are at the point where
>pioneer town X needs to start collecting taxes and erecting law and order=
>order to keep growing. Well you've all played SimCity so you know.
>Squeakfoundation mailing list

  - Joseph Pelrine [ | ]
Daedalos Consulting
Email:  jpelrine@acm.org
Web:    www.daedalos.com/~j_pelrine

Smalltalk - scene and not herd!