Reimplement some explicitly required methods to speed up shapes

[jecisc]

explicitRequirement is really slow in the case were a method is implemented already in the superclass and this slow down a lot some visualizations. I propose to explicitly define the super call to get a huge speed up on shapes (This allows to save a lot of times in the Moose visualizations)

[Ducasse]

Can we remove explicit requirement instead? Adding such code are bad.

[jecisc]

Personally I like to have those methods because it means "Those methods needs to be there for the trait to work" like we have self subclassResponsibility to say "I'm an abstract class and this method is needed". And that helps a lot when we use a Trait we do not know.

But if asked to, I can remove them.

[Ducasse]

I know you like them but they do not fit with our world. I would like to have in the signature of method the exception that they raised but this is not like that in Pharo

[guillep]

If traits were more intelligent and not install methods defined in superclasses, would that solve your problem? This of course means that adding a method in a class should recompute the "subclass responsibility/requirements" in subclasses.

Alternatively how would you feel if the classes importing a trait do never import explicit requirement methods? This means, the explicit requirement is in the trait to express the requirement, but it's not installed/compiled/copied into the class, thus producing a DNU at runtime (which is not different from the requirement error).

[jecisc]

Those were options we talked about with Pablo and I'm fine with both. We just did not start this work because it requires time

[Ducasse]

I like the second one more than the first one (did not think a lot about them). We could still build on the second one to have a tool checking that the trait is complete. We would have to go from the class to its traits check all the methods to identify the explicit requirements. So it looks ok to me. I prefer that than being forced to check all the subclasses.