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.
I have no constraint about method belonging to only one package.
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.
I see what you mean. Overrides hell. Now this is MC that defines the semantics not the package and I do not want to substitute MC just having a fast implementation of PackageInfo. But I was wondering how I would implement it to understand if the package should provide a specific infrastructure or just a list to start with. Stef