On May 30, 2013, at 9:44 AM, Goubier Thierry <[email protected]> wrote:
> Le 29/05/2013 23:16, stephane ducasse a écrit : >> >> On May 29, 2013, at 9:08 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. >> >> 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
