Template overriding rework

[Ron Smith]

There's a couple issues with the template overriding mechanism, specifically:

• The mechanism for calling the 'next' method in the chain isn't OO nor elegant (call next_methodName())
• The additional generated methods are interfering with editing XTend files as Torsten describes [1]

I'm thinking of changing the template overriding as follows.  Let me know what you think.

The main features are:

• Template, override, and extension classes have no additional methods.  Only base class is changed.
• Base class is generated that dispatches to head of chain for each method.
• Template, override, and extension classes get reference to 'next' class that will dispatch to next method in the chain.

Let me know what you think.  This is more elaborate in terms of number of classes, but simpler in terms of modifications to the classes, and should address the two issues.  Simpler solutions very welcome.

--Ron

[Torsten Juergeleit]

I'm fine with this approach. I guess some of the reasonings can be found in the comments to issue #45.

Keep in mind that there are Xtend-related requirements to cope with, e.g. every overridable template method has to use the keyword "override" instead of "def".

/Torsten

[Pavel Tavoda]

I did small research. Attached is small test. It shows interesting results for me.

If I compare best with worst case I found 13ms difference for calling simple/empty method 10 million times.

Aren't we really solving non-existing problem? I would really like hear you thought about this. For me what we are generating is overcomplicated but till it's working, I'm fine with it.

However I'm still not very happy with next-Xxx methods. After applying annotation on e.g. Properties, try to press CTRL+SPACE in some template using static import of Properties.

My detection of 'dispatch' method is simple. I remember all _Xxx and check if here is also Xxx method with same signature.

        protected static def getOverrideableMethods(MutableClassDeclaration annotatedClass) {

               val noTransform = annotatedClass.declaredMethods.filter[m | m.simpleName.startsWith("_")].map[m | m.simpleName.substring(1)].toSet

               annotatedClass.declaredMethods.filter[m | m.static == false &&

                       (m.visibility == Visibility::PUBLIC && !noTransform.exists[it == m.simpleName])

                       || (m.visibility == Visibility::PROTECTED &&  noTransform.exists["_" + it == m.simpleName])

               ].toList

        }

Regards

Pavel

[Torsten Juergeleit]

Great, with the new approach I can see fewer generated methods in the editors outline: Only "_methodsDispatchHead()" and another one
Can we get rid of the accessor "_methodsDispatchHead()" by using a public attribute instead?

Btw. how about using a different prefix for the generated methods to get them at the end of the alphabetically sorted list of methods in the editors outline or code completion?

/Torsten


On Thursday, 1 August 2013 05:55:44 UTC+2, Ron Smith wrote:

[Pavel Tavoda]

Yes, now it looks much better and _xxx_ looks always better than _chained_ ;-).

[Torsten Juergeleit]

• The additional generated methods are interfering with editing XTend files as Torsten describes [1]

This issue isn't gone with the new approach. From the attached screenshot you can see that we have every method duplicated.

/Torsten

On Thursday, 1 August 2013 05:55:44 UTC+2, Ron Smith wrote: