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
squeakfoundation@lists.squeakfoundation.org