I have a question about RPackage and overrides. RPackage consider that an override method is an extension, right? What would be the difference between an extension and an override, apart from the protocol name? Is it usefull to have a difference? (i.e. if you missclassify a method between extension and override, what happens? Nothing?) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded. I do not know if this answer your question.
What would be the difference between an extension and an override, apart from the protocol name? Is it usefull to have a difference? (i.e. if you missclassify a method between extension and override, what happens? Nothing?)
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping).
I do not know if this answer your question.
Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same. What do you think? Is it important to classify overrides as such, or just let them be extensions ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping).
I do not know if this answer your question.
Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same.
What do you think? Is it important to classify overrides as such, or just let them be extensions ?
The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it? Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. Nobody ever should do overrides, because it will just not work as soon as it is used a lot. Marcus
Le 29/05/2013 09:07, Marcus Denker a écrit :
On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping).
I do not know if this answer your question.
Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same.
What do you think? Is it important to classify overrides as such, or just let them be extensions ?
The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it?
Oh, yes :(
Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. Nobody ever should do overrides, because it will just not work as soon as it is used a lot.
So, what do we do ? - Don't model and don't track overrides, even if some packages are effectively using them. - Model overrides so that we can: - Detect when a package is creating an override (a Lint rule?) - Signal an error for an override of an override (upon loading, for example). - Signal an error when updating a package changes an extension to an override. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On May 29, 2013, at 9:17 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 29/05/2013 09:07, Marcus Denker a écrit :
On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping).
I do not know if this answer your question.
Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same.
What do you think? Is it important to classify overrides as such, or just let them be extensions ?
The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it?
Oh, yes :(
Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. Nobody ever should do overrides, because it will just not work as soon as it is used a lot.
So, what do we do ?
- Don't model and don't track overrides, even if some packages are effectively using them.
The thing is that there are much more important things to fix in RPackage⦠I don't even have the mental capacity to think about it. So prefer this for now. Marcus
- Model overrides so that we can: - Detect when a package is creating an override (a Lint rule?) - Signal an error for an override of an override (upon loading, for example). - Signal an error when updating a package changes an extension to an override.
Goubier Thierry wrote
So, what do we do ?
Maybe create an issue with "later" milestone pointing to this discussion? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-RPackage-and-overrides-tp4690435p4690606.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 29/05/2013 14:39, Sean P. DeNigris a écrit :
Goubier Thierry wrote
So, what do we do ?
Maybe create an issue with "later" milestone pointing to this discussion?
Done. https://pharo.fogbugz.com/default.asp?10790 Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 29 May 2013 09:07, Marcus Denker <marcus.denker@inria.fr> wrote:
On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping).
I do not know if this answer your question.
Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same.
What do you think? Is it important to classify overrides as such, or just let them be extensions ?
The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it?
Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. Nobody ever should do overrides, because it will just not work as soon as it is used a lot.
+1 package should be able to only tell what it contains: - classes - extension methods To tell, if given extension method overrides existing method or not, package must have knowledge about the system it is going to be installed into. And since such knowledge is external to package, you should not manage it at package level - it is a global system level (package manager or alike). If you attempt to deal with that at package level, you'll introduce more problems than solve.
Marcus
-- Best regards, Igor Stasenko.
On May 29, 2013, at 9:08 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not.
We do not support this "feature" since it is bogus since years.
RPackage does not (and list -overrides as extensions, as for example in Keymapping).
I do not know if this answer your question.
Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same.
What do you think? Is it important to classify overrides as such, or just let them be extensions ?
just extensions. Stef
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 29/05/2013 23:16, stephane ducasse a écrit :
On May 29, 2013, at 9:08 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not.
We do not support this "feature" since it is bogus since years.
Then you just have to ensure that integration rejects overrides (and that the IDE does as well: I'm sure I can create overrides in Pharo, isn't it?).
RPackage does not (and list -overrides as extensions, as for example in Keymapping).
I do not know if this answer your question.
Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same.
What do you think? Is it important to classify overrides as such, or just let them be extensions ?
just extensions.
Makes my life simpler ;) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On May 30, 2013, at 9:44 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 29/05/2013 23:16, stephane ducasse a écrit :
On May 29, 2013, at 9:08 AM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 28/05/2013 22:23, stephane ducasse a écrit :
I have a question about RPackage and overrides.
RPackage consider that an override method is an extension, right?
for RPackage a package is a list of method definitions and class definition. There is no specific tagging for overriding methods that would magically reappear when their overriding method would be unloaded.
Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not.
We do not support this "feature" since it is bogus since years.
Then you just have to ensure that integration rejects overrides (and that the IDE does as well: I'm sure I can create overrides in Pharo, isn't it?).
Yes. I can say true become: false, too. Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes the image package dirty. So later, when I know what I want, I will move that change to the image. You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things. So this is more something we should add a rule for in Code Crititque⦠Marcus
On May 30, 2
Yes. I can say true become: false, too.
Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes the image package dirty. So later, when I know what I want, I will move that change to the image.
You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things.
So this is more something we should add a rule for in Code Crititqueâ¦
I'm not sure. Because something you really need them. Stef
Le 30/05/2013 14:09, Stéphane Ducasse a écrit :
On May 30, 2
Yes. I can say true become: false, too.
Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes the image package dirty. So later, when I know what I want, I will move that change to the image.
You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things.
So this is more something we should add a rule for in Code Crititqueâ¦
I'm not sure. Because something you really need them.
I'd be worried then. Either we have a need for extension where only an override will do... Then why not modeling it and critique it when appropriate? Hiding it under an extension won't make the problem disappear, it will just hide it. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On May 30, 2013, at 2:22 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 30/05/2013 14:09, Stéphane Ducasse a écrit :
On May 30, 2
Yes. I can say true become: false, too.
Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes the image package dirty. So later, when I know what I want, I will move that change to the image.
You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things.
So this is more something we should add a rule for in Code Crititqueâ¦
I'm not sure. Because something you really need them.
I'd be worried then.
Either we have a need for extension where only an override will do... Then why not modeling it and critique it when appropriate? Hiding it under an extension won't make the problem disappear, it will just hide it.
But it just does not work: two overrides. Which will be called? Overrides are like halt: you use is while developing and for hacks, but shipped packages just can not use it, because there is just no semantic of multiple overrides. The only solution is to have system where extensions are private to you, but than the normal use case for overrides is to "hook into something". Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOS⦠But as I said: my brain is full. I just can't think about it now. Marcus
Le 30/05/2013 14:27, Marcus Denker a écrit :
On May 30, 2013, at 2:22 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 30/05/2013 14:09, Stéphane Ducasse a écrit :
On May 30, 2
Yes. I can say true become: false, too.
Overrides can be interesting as a temperer hack. E.g. in Opal development, I might add an override just to test. Then loading Opal makes the image package dirty. So later, when I know what I want, I will move that change to the image.
You should not use overrides as a concept in delivered software (as it does not work), so modeling it is wrong as then people will use it. Yes making it impossible is not nice either, because temporarily I want to be able to just do it, like I can do all sorts of things.
So this is more something we should add a rule for in Code Crititqueâ¦
I'm not sure. Because something you really need them.
I'd be worried then.
Either we have a need for extension where only an override will do... Then why not modeling it and critique it when appropriate? Hiding it under an extension won't make the problem disappear, it will just hide it.
But it just does not work: two overrides. Which will be called? Overrides are like halt: you use is while developing and for hacks, but shipped packages just can not use it, because there is just no semantic of multiple overrides.
I don't see the point. Overrides are not an executable concept, they are a package management concept. At execution, only methods do exist. How two overrides (or even one method and one override) work are the duty of the package management system. If the package management system forbid loading two overrides, it's fine by me. If, as an integrator, you reject any fix with an override, its fine by me. If you decide to let it pass, then its fine by me too ;) What I don't like is, we have a way to say we are hacking into the system in a not so nice way to hook somethin. It's bad, it looks bad, but it's documented and appears as such. Now, hiding it as an extension is making a lot worse: it's an override, we can do it, and its hidden unless you chase the package which changed when it shouldn't (and in some cases, like loading a package with an hidden override in an image with unsaved changes can make the search for it an interesting task...)
The only solution is to have system where extensions are private to you, but than the normal use case for overrides is to "hook into something".
An override is a hook when the underlying system you hook into wasn't planned to be used that way. Which I say is probably a sign of bad design :(
Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOSâ¦
This looks really complex. We have a lot of reflective features available to allow for nice hooks (flags and just plain subclass queries as in Monticello repositories), no need to think about how to make clever overrides (Unless you want to make a paper and get it into, say, Scala :)).
But as I said: my brain is full. I just can't think about it now.
But I'm enjoying that :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
For marcus and igor. Now when we work on the core you have some methods with some behavior and since you want to have a small kernel you define some methods in a certain way. Now after you want to load code on top and suddenly you want to change the behavior to use the loaded package. And I do not see how you do it without override (yes you can define a block and get all the core behavior customisable via block and propose setters fro these blocks. Of course there is a risk that another package may override the same methods but the risk is low.
I don't see the point. Overrides are not an executable concept, they are a package management concept. At execution, only methods do exist. How two overrides (or even one method and one override) work are the duty of the package management system.
yes :)
If the package management system forbid loading two overrides, it's fine by me. If, as an integrator, you reject any fix with an override, its fine by me. If you decide to let it pass, then its fine by me too ;)
For me so far I'm pragmatic. I will push design that avoid override but I will be pragmatic because sometimes we need that.
What I don't like is, we have a way to say we are hacking into the system in a not so nice way to hook somethin. It's bad, it looks bad, but it's documented and appears as such. Now, hiding it as an extension is making a lot worse: it's an override, we can do it, and its hidden unless you chase the package which changed when it shouldn't (and in some cases, like loading a package with an hidden override in an image with unsaved changes can make the search for it an interesting task...)
An override is a hook when the underlying system you hook into wasn't planned to be used that way. Which I say is probably a sign of bad design :(
Not necessarily but often it shows that we could anticipate more.
Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOSâ¦
This looks really complex. We have a lot of reflective features available to allow for nice hooks (flags and just plain subclass queries as in Monticello repositories), no need to think about how to make clever overrides (Unless you want to make a paper and get it into, say, Scala :)).
But as I said: my brain is full. I just can't think about it now.
But I'm enjoying that :)
Me too. I worked a lot on method extension (basically the PhD of alex) and we did not find a good solution. May selector namespace but this requires a lot of work.
On 30 May 2013 21:02, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I don't see the point. Overrides are not an executable concept, they are a package management concept. At execution, only methods do exist. How two overrides (or even one method and one override) work are the duty of the package management system.
yes :)
If the package management system forbid loading two overrides, it's fine by me. If, as an integrator, you reject any fix with an override, its fine by me. If you decide to let it pass, then its fine by me too ;)
For me so far I'm pragmatic. I will push design that avoid override but I will be pragmatic because sometimes we need that.
What I don't like is, we have a way to say we are hacking into the system in a not so nice way to hook somethin. It's bad, it looks bad, but it's documented and appears as such. Now, hiding it as an extension is making a lot worse: it's an override, we can do it, and its hidden unless you chase the package which changed when it shouldn't (and in some cases, like loading a package with an hidden override in an image with unsaved changes can make the search for it an interesting task...)
An override is a hook when the underlying system you hook into wasn't planned to be used that way. Which I say is probably a sign of bad design :(
Not necessarily but often it shows that we could anticipate more.
Maybe something on the sub-method level? Packages could register methods to be called before and after like in CLOSâ¦
This looks really complex. We have a lot of reflective features available to allow for nice hooks (flags and just plain subclass queries as in Monticello repositories), no need to think about how to make clever overrides (Unless you want to make a paper and get it into, say, Scala :)).
But as I said: my brain is full. I just can't think about it now.
But I'm enjoying that :)
Me too. I worked a lot on method extension (basically the PhD of alex) and we did not find a good solution. May selector namespace but this requires a lot of work.
ohohoho.. selector namespaces.. sounds like using nuclear weapon to get rid of cockroaches: - solution is totally inadequate for given problem (overrides are really rare) - new model could bring more problems than it solves (as nuclear weapon does ;) But i agree with Goubier that we should do something about it.. But it is what is not finished for RPackage: - make packages to be not some "ad-hoc" entity which lives parallel to system model, but a real citizen of it. Like that: - adding, removing, renaming.. anything related to methods which belongs to package should be controlled by package. Then package can reason what is allowed to do and what is not. And we should get there eventually: - Stef, you are pushing "manifests".. now imagine that manifest is not something (again) external, but the rules defined for package how to manage changes. For example, it can enforce some rules, like: no extensions allowed (so attempting to add any extension will result in error, and no method will be installed), or no removals, no uncategorized methods etc.. Or going further: run lint rule on newly compiled method, and refuse to install new method until developer can make it happy ;) -- Best regards, Igor Stasenko.
On 31 May 2013 09:00, Norbert Hartl <norbert@hartl.name> wrote:
Am 31.05.2013 um 02:56 schrieb Igor Stasenko <siguctua@gmail.com>:
ohohoho.. selector namespaces.. sounds like using nuclear weapon to get rid of cockroaches:
You know that cockroaches are the ones that will survive a nuclear strike ? :)
yes, i know. And that's why i was using this metaphor :)
Norbert
-- Best regards, Igor Stasenko.
participants (7)
-
Goubier Thierry -
Igor Stasenko -
Marcus Denker -
Norbert Hartl -
Sean P. DeNigris -
stephane ducasse -
Stéphane Ducasse