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.