Overrides in CSPs (Re: Branding criteria (was: Re: [squeak-dev]
Modularity))
Chris Muller
asqueaker at gmail.com
Thu May 5 01:16:03 UTC 2011
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
More information about the Squeak-dev
mailing list
|