<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/27/2013 12:21 AM, Florin Mateoc
wrote:<br>
</div>
<blockquote cite="mid:52958152.6000303@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Eliot,<br>
<br>
On 11/26/2013 7:15 PM, Eliot Miranda wrote:<br>
</div>
<blockquote
cite="mid:CAC20JE1YsBBHYVdOn4edmBU0UwJrp2aF822XAe9x-VxjGPYcTw@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Florin,<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Nov 22, 2013 at 8:35 AM,
Florin Mateoc <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span>
wrote:<br>
</div>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAC20JE1YsBBHYVdOn4edmBU0UwJrp2aF822XAe9x-VxjGPYcTw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I
think overrides (a la VW, but they could be done even
better) </blockquote>
<div><br>
</div>
<div>+1. I was the guilty party that f**ed up the
implementation of the VW ones (but then it was my idea
also). See <a moz-do-not-send="true"
href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.html">http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-January/142760.html</a>
for a better approach to implementation. Does it make
sense to you?</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">could
solve these entanglement problems much easier<br>
(after the initial investment), directly attacking
modularity and helping address other issues in this
area:<br>
loading/unloading, minimal image, versioning.<br>
<span class=""><font color="#888888"><br>
Florin<br>
</font></span></blockquote>
</div>
<div><br>
</div>
-- <br>
best,
<div>Eliot</div>
</div>
</div>
</blockquote>
<br>
<br>
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). <br>
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).<br>
<br>
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.<br>
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...<br>
<br>
Cheers,<br>
Florin<br>
</blockquote>
<br>
Just a couple of clarifications, I may have been too succinct.<br>
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.<br>
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)<br>
<br>
Florin<br>
</body>
</html>