[Pharo-project] Fwd: semantics of overrides
Hi
I'm starting to think to add override to my new implementation of Package. Now I wonder how PackageInfo keeps information the fact that when an overridding method is unload, the overridden is added back to the class. May be this is MC that does this? Does anybody knows about it?
Then I have also another question related to the order
P1>>*m p1 P2>>*m p2 P3>>*m p3
right now is the load order preserved? ie does P3 takes precedence over p2 and p1
If I unload P2 and P3 do I get P1, I remember that alex got problems with that some years ago.
Stef
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.
Then I have also another question related to the order
   P1>>*m            p1    P2>>*m            p2    P3>>*m            p3
right now is the load order preserved? ie does P3 takes precedence over p2 and p1
I don't understand that question/syntax. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Dec 23, 2009, at 9:37 AM, Lukas Renggli 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
Then I have also another question related to the order
P1>>*m p1 P2>>*m p2 P3>>*m p3
right now is the load order preserved? ie does P3 takes precedence over p2 and p1
I don't understand that question/syntax.
*m means that the package P1 overrdies m1 and return ^ 'p1' Originally I did not like overrides but sometimes you cruelly need them and I want package to be backwards
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Dec 23, 2009, at 1:15 PM, Lukas Renggli 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.
yes this was my example.
I think a better strategy is to allow methods to be defined in multiple packages.
I have that in RPackage but not the unload semantics and tagging of override
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.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
participants (3)
-
Eliot Miranda -
Lukas Renggli -
Stéphane Ducasse