Le 29/05/2013 09:07, Marcus Denker a écrit :
On May 29, 2013, at 9:04 AM, Goubier Thierry <[email protected]> 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
