On May 29, 2013, at 9:17 AM, Goubier Thierry <[email protected]> wrote:
> 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. > 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.
