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