Fwd: semantics of overrides
Locked
 
|
> 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 > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: semantics of overrides
|
|
>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: semantics of overrides
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: semantics of overrides
|
|
>>>> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: semantics of overrides
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: semantics of overrides
|
|
In reply to this post by Lukas Renggli
On Wed, Dec 23, 2009 at 4:15 AM, Lukas Renggli <[hidden email]> wrote:
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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Fwd: semantics of overrides
|
|
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |