[squeak-dev] The Trunk: MonticelloConfigurations-fbs.118.mcz

Florin Mateoc florin.mateoc at gmail.com
Wed Nov 27 05:21:22 UTC 2013


Hi Eliot,

On 11/26/2013 7:15 PM, Eliot Miranda wrote:
> Hi Florin,
>
>
> On Fri, Nov 22, 2013 at 8:35 AM, Florin Mateoc <florin.mateoc at gmail.com <mailto:florin.mateoc at gmail.com>> wrote:
>
>     I think overrides (a la VW, but they could be done even better) 
>
>
> +1.  I was the guilty party that f**ed up the implementation of the VW ones (but then it was my idea also).  See
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.html for a better approach to
> implementation.  Does it make sense to you?
>  
>
>     could solve these entanglement problems much easier
>     (after the initial investment), directly attacking modularity and helping address other issues in this area:
>     loading/unloading, minimal image, versioning.
>
>     Florin
>
>
> -- 
> best,
> Eliot


I actually liked overrides a lot - I should have emphasized that (especially that there are seemingly so many things
that I don't like :) - must be the age).
It was, from my point of view, the one saving grace for Store (as compared to Envy, which was otherwise fantastic (and
it had atomic loading).

I am sorry, I did not really understand your alternative approach from that message. What I had in mind was, on one
hand, to remove any restrictions for what an override can do (I don't remember exactly, but I think there were some
unnecessary restrictions), on the other hand, specify in the override itself what it expects the overidee to be. These
override expectations should be in the form of source code (method formatted source, class structure...), not versions
or some such.
The fact that the override specifies its expectations not only makes it likely that it will work when they are met, but
also implies that they were tested in that configuration by their developer. The expectations for each override should
be a collection, not a single source, since this would allow to load multiple packages that override the same things.
One of the expectations would be the base variation, another would be after a known other package overrode it...

Cheers,
Florin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131127/ac9fb602/attachment.htm


More information about the Squeak-dev mailing list