> 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
