Quoting you - ("Sorry, newcomer X, but your code's just too shaky, we'll have to pass on that for now")
Please start by reading the numerous writings on modularity in Smalltalk before posting things like this. Joseph
At 14:37 02.06.2001 , Henrik Gedenryd wrote:
My idea is that we need a simple but powerful overall principle of organization.
(According to this proposal) we should adopt a variant of the well-known "layered" or "onion-skin" architecture, along with a principle that ensures sustainability:
(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 a 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 necessities.
Comments:
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: the
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é)
- 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 to 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 updating 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 of 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 in order to keep growing. Well you've all played SimCity so you know.
Henrik
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
-- - Joseph Pelrine [ | ] Daedalos Consulting Email: jpelrine@acm.org Web: www.daedalos.com/~j_pelrine
Smalltalk - scene and not herd!