[Squeakfoundation]An architecture for sustainable Squeaking

Sat, 2 Jun 2001 17:13:06 +0300

I'd like to make this more concrete, if you don't mind -
I've posted recently modifications to the Browser (See HintingBrowser).
In a word, this code annotates method names in the Browser according to
how complicated they are. I wrote experimental all over them in big red
ink, because they change the Browser, and they are hacks (made it work,
have not made it "right"). My hope was to see whether someone else
thinks this might be useful, and if so, I'd refactor them enough to put
in the image, or at least for me to recommend them to anyone.

This experience raises several questions -
1. How deep is the Browser? it's an application, but editing it sure
felt like modifying core. What standards should apply to it?
2. How do we see people making modifications such as this? Whos the
Browsers keeper (near-pun alert ;-), and what standards should he hold
code to?

Here's a short analysis of my modification (the anatomy of a quick hack)
-
I changed two classes - Browser (Application, but central) and
PluggableListMorph (Middle-deep)
And added one - MethodSubstitute (Could be used by various different
tool, but it isn't, because it's taken from BobsBrowser, that never
quite made it into the image. A MethodSubstitute identifies a compiled
method by knowing it's class and name and whether it's on the class
side).

The Browser mods -
#messageList was made to return lists of MethodSubstitutes instead of
Strings. This makes it higher-level, refering to domain objects rather
than to Strings, so it's not intrinsically bad, but it also makes it
incompatible with PluggableMorphLists, which expect to get strings.
#selectedMethodName was changed to convert the selected MethodSubstitute
into a String.

The PluggableListMorph mods -
in #list:, I extracted a method for the creation of Morphs representing
the list items. This protects the code somewhat from my changes to this
functionality.
#morphForItem: uses #stringForMethod: and methodPrefix: to implement the
actual creation of morphs that display MethodSubstitutes appropriately.
Of course the functionality of these two (three?) latter methods has
nothing to do with PluggableListMorph. They're there temporarily,
waiting to be replaced by a Strategy object or something similar.

Basically, the problem I met doing this code is this - 
I can do the changes quickly, but in a way that would hurt important
code. 
I can also make the changes be nice refactorings, but who said these
refactorings ARE acceptable changes to such important code? maybe
someone can think of something better. So before I invest time in doing
these right, let's see what people say...

So for now the result for now is we have Yet Another Goodie. Life
expectancy - Zilch.

I think we're in need of a Linus here... (technically respected person
that's willing to put in Major Time and Effort in doing quality and
integration work). We're very lucky in the
legend-class-affiliated-programmers department, but their interests
focus elsewhere...

1. Any takers?
2. How do people think these needs get solved? including under the
onion-regime.

Henrik Gedenryd <Henrik.Gedenryd@lucs.lu.se> 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