On 11/27/2013 12:21 AM, Florin Mateoc wrote:
> 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

Just a couple of clarifications, I may have been too succinct.
I would call this structural matching for projects insetad of nominal and it seems much more robust. You match more on
semantics (code) rather than some convention, where the match can fail because a project bumped its version number only
to add a readme.
Also notice how this also makes order of project loading irrelevant, as it should be. Of course, sometimes projects do
depend/build on each other, and that would be reflected in the overrides expectations - the order would be imposed,
potentially automatically, by what is in the overrides and their expectations -  but when they just happen to clash on
some overrides, order is irrelevant. In such situations, it is enough for one project to be aware of the other one, and
they can be loaded in whatever order. Say project A overrides method m from base, but is aware that sometimes people
also have project B loaded, which also overrides method m. Then A can be loaded whether B is loaded or not. B can also
be loaded, even if A is already loaded, since it "sees" that method m expects its own variation of method m, so it can
rely on project A's variation instead (this may mean that the override itself, not just its expectations, has several
incarnations, depending on what it finds already loaded)

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