Overrides in CSPs (Re: Branding criteria (was: Re: [squeak-dev] Modularity))
Locked
Overrides in CSPs (Re: Branding criteria (was: Re: [squeak-dev] Modularity))
 
|
I must admit that lately I've been fairly sold on using SqueakMap to manage Community Supported Packages, or "CSP"s (gah, a TLA. How irresponsible.) It works nominally now and we can always improve it.
Further comments inline.
On Wed, May 4, 2011 at 6:09 AM, Levente Uzonyi <[hidden email]> wrote:
Overrides, right? I learned to loathe them passionately while completely failing to keep Polymorph working in the Trunk when I first entered the community. In the course of doing my Theme engine prototype in Cuis, Juan and I found that in many ways such a system can be greatly simplified in comparison by baking the behavior of the necessary overrides and workarounds into the core system, or hanging hooks to attach the behavior to when the external package is installed. The amount of complexity this adds to the core system is rarely increased by a great degree -- it just needs the right little hooks in the right places.
Since my Theme engine was only one class wide, and the simplest solution involved the system needing at least one Theme (the default) installed in order to function, we ended up including Theme in the core of Cuis. But the vast majority of the work was about a) baking behavior which would otherwise need to be overridden and was necessary or convenient for reuse into the core system, and b) massaging out the behavior that I would ordinarily have had to override which made less sense where it was into the Theme class itself, which was originally intended to work as a loadable package.
The result ended up being looser coupling between structure and presentation in the user interface surface and less code overall. The work isn't done completely done, as there is still UI surface that I don't yet cover, and code cleanup to be done (I had to look all over Morphic to figure out where all of UI I wanted to skin was coming from, and make changes all over the place) but It Worked (TM).
I do agree with Levente that we should avoid overrides in CSPs wherever possible, even if that means doing the work to remediate the implementations of the packages we maintain. Of course, I am not currently a CSP maintainer, so I'm not sure I'm qualified to tell CSP maintainers what they should and shouldn't do:)
OTOH, I suppose it may be more important to keep these packages updated and tested with each release than to let them languish for want of some massive refactoring to remove overrides while the core system diverges in the Trunk. So maybe no-overrides is a counter productive rule. I don't know for sure. I wish we could remove the feature from PackageInfo/Monticello entirely, frankly, so that we can at least stop the bleeding right now.
Sure. Is this a bridge we can cross when we come to it? Potential application of the YAGNI Principle?
My point is that Connectors is fine on it's own at the moment, users are happy with it, but it doesn't play well in a larger system. The overrides ("stolen" methods) can break the base system and other packages in the future, while the insufficient number of tests may not prevent Connectors being broken by future changes of the base system. Okay, first off, objection. How many tests are enough tests? How do you measure that? Code coverage is usually a tricky metric, because there are different granularities at work under the same monicker (e.g., line-level coverage, block level coverage, method level coverage, etc.) and what code coverage really tells you is what you know for sure that you *aren't* covering. It never gives you a clear view into what you *are* covering. I mean if your gut is telling you "there aren't enough tests here," I can identify with that, but if we're going to make a rule about it, it will have to be completely arbitrary, won't it? No subjective rule will ever work.
Can we put in place a process around addressing such problems? To my mind, the situation is golden until we recognize that one of these regressions has occurred. When such a regression is identified, the package can be flagged as #broken on SqueakMap. We can even make the UI warn the user if he or she attempts to install something that's been marked as broken. It can then be fixed to work in the context of the release that it's broken in, and the #broken flag may be removed. This way we can maintain external packages in the context of updates to a release.
Does this seem like a good idea? I am I making any invalid assumptions about what SqueakMap can be made to do easily?
+1, and we should remove this from the language we use to describe CSPs, too. Find a way to say what we mean without inadvertently implying that there's a warranty.
-- Casey Ransberger |
Re: Overrides in CSPs (Re: Branding criteria (was: Re: [squeak-dev] Modularity))
|
|
Good note. Some brief comments in-lined.
> community. In the course of doing my Theme engine prototype in Cuis, Juan > and I found that in many ways such a system can be greatly simplified in > ... > The result ended up being looser coupling between structure and presentation > in the user interface surface and less code overall. The work isn't done > ... > place) but It Worked (TM). In summary, what I took from that was how, sometimes, it's really nice to have _modifiable_ system; including at the system-level classes and below, even if it means you have a dirty package. I absolutely agree these are exceptional cases; like maybe a video game, for example. But modifiable is core to Squeak philosophy and something I want my package-loader to be able to do. I also want my package-loader to allow me to _browse_ the contents before I install it, so I can make sure it won't format my HD. SqueakMap has that, of course. > I do agree with Levente that we should avoid overrides in CSPs wherever > possible, even if that means doing the work to remediate the implementations I absolutely agree, which is exactly what happened with Connectors; I reduced the number of "overrides" from a couple of hundred down to just the 3 or 4 which weren't slam-dunk easy. > of the packages we maintain. Of course, I am not currently a CSP maintainer, Yes you are; CSP means "Community Supported Package" and you are part of the community. You or anyone can add a new release of Connectors right now if you wanted. > So maybe no-overrides is a counter productive rule. I don't know for sure. I > wish we could remove the feature from PackageInfo/Monticello entirely, > frankly, so that we can at least stop the bleeding right now. For overrides, I prefer change-sets. BUT, I want to explain how I deployed Magma 1.2 on a *modified* Pharo 1.1 and 1.2 platform using SqueakMap without using ChangeSets and without using MC overrides. In a separate post.. > Can we put in place a process around addressing such problems? To my mind, > the situation is golden until we recognize that one of these regressions has > occurred. When such a regression is identified, the package can be flagged > as #broken on SqueakMap. > ... > Does this seem like a good idea? I am I making any invalid assumptions about > what SqueakMap can be made to do easily? I don't think this is necessary because we have the #bleedingEdge release, which carries enough connotation to lower expectations. It's the version that is meant to be taken up with trunk development. The #bleedingEdge script for a package is written just once and then never needs to change, unless new functionality introduces a new package dependency, of course, but this is rare). Then there are the legacy releases of packages which are targeted always at some _legacy_ Squeak release. The legacy release scripts never need to change because the legacy Squeak release doesn't change (unless someone wants to backport a bug fix, which is rare). > +1, and we should remove this from the language we use to describe CSPs, > too. Find a way to say what we mean without inadvertently implying that > there's a warranty. Yep. - Chris |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |