On Wed, Dec 23, 2009 at 4:15 AM, Lukas Renggli
<renggli@gmail.com> wrote:
>>>> May be this is MC that does this? Does anybody knows about it?
>>
>> MC uses the changes file to restore methods that are put into an
>> *packagename-override protocol, see MCMethodDefinition>>#unload.
>> Practically this does not work, because it makes all kind of generally
>> invalid assumptions.
>
> Thanks lukas.
> OK I have the impression that the package should know m1 is an override
> and when I unload I should put back the method I overrode but
That is not that simple, because packages can be unloaded in a
different order they are installed. I think a better strategy is to
allow methods to be defined in multiple packages.
Right. �Maintain a global package load order. �Maintain a dictionary from method reference to set of package/method pairs for each method that is overridden. �When a package is removed search overrides and compute the overridden methods to be reinstalled, computing the uppermost method depending on the new package order.
A package could mean for example an MC package and loading a new version of a package is an unload of the old version and a load of the new version. �This is important to avoid overrides building up. �The system must effectively GC overrides for unloaded packages so that the overridden methods only correspond to loaded packages.
When I first tried this in VW with parcels I got the data structure badly wrong and chose a stack per override, ad had no global load order, because I hadn't thought through the arbitrary load/unload order properly. �But I think sets of overrides plus a global load order will work.