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.<div><br>
</div><div>Further comments inline.<br><br><div class="gmail_quote">On Wed, May 4, 2011 at 6:09 AM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu">leves@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, 3 May 2011, Chris Muller wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
see "Connectors" as a working example of this,<br>
</blockquote>
<br>
"* No conflicts. Neither class names nor -override categories. The<br>
rationale is that all community supported packages can be loaded<br>
together without creating conflicts."<br>
<br>
Collections, Kernel and System are dirty after loading Connectors, because<br>
it's "stealing" methods.</blockquote></blockquote></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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:)</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, but that's just a shallow problem with Connectors, not a problem<br>
with the process or tools.<br>
</blockquote>
<br></div>
Currently it'a shallow problem, but if we want to maintain several (100+) community supported packages (and I guess we do), then it's have a great potential to break the system.</blockquote><div><br></div><div>Sure. Is this a bridge we can cross when we come to it? Potential application of the YAGNI Principle?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Does this seem like a good idea? I am I making any invalid assumptions about what SqueakMap can be made to do easily?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Before we subject ourselves to rules, let's ask what is the basis for<br>
needing them? From Andreas' original note:<br><snip> </blockquote></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The goal is stated as, "one-click loadable" and "we provide assurance"<br>
(which is difficult especially when one reads MIT license), but I<br>
think this might be about _branding_.<br>
</blockquote>
<br></div>
Don't take assurance literally, it only means that you can expect it to work out of the box.</blockquote><div><br></div><div>+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.</div>
</div><br clear="all"><br>-- <br>Casey Ransberger<br>
</div>