Community
Participate
Working Groups
Build Identifier: Currently the xtend editor doesn't support the "create method" refactoring as the java editor does. For example, assume I'm creating a class like: 1 class ZombieScout { 2 3 def scout() { 4 val zombiesFound = isZombiesHere(); 5 if (zombiesFound) { 6 startShooting(); 7 } 8 } 9} So as I'm typing (at my highest business-ey level of abstraction) and I get to line #4 no method names isZombiesHere exists. In the java editor, I almost without thinking just hit ctrl+1 and it offers me a quick-fix of "create method isZombiesHere()" which I hit enter, and then it invokes the template allowing me to fill in the param types and names and return types or accept the defaults. Same would be true of line #6 as well. Then once I have my high level scout() method, I go flesh out the private helper isZombiesHere() and startShooting() methods. This is a pretty big deal for me because I just do it all the time, but maybe that's not very typical. This was on the list of top 15 refactorings as discussed on Bug 364678 Reproducible: Always
After having a look at JDT I see that templateProposals are used there. Is this also a way to go for us or should we keep it simple and suggest the most common signature for a function. Next is that JDT inferres the returnType of a possible mothod by looking at the context of the call. I think we could do this too. Any opinions?
Having templates is very cool and desirable. But if that is much more work, it's a good idea to start with a working but simpler version first.
Now we have a quickfix to add a method or a field. Depending on the context both can be valid. There is quickfix to create a field when there are no parameters in the FeatureCall. pushed first shot to master. Please review. Thought about adding quickfixes for following szenario: class Type { def foo(OtherType it){ -> bar } } bar could be a method or field in Type ot OtherType. To achieve this we could not use the infrastructure that is currently there because it relies on documentChanges and we do not have a document for OtherType. The XtextResource could handle replacements by offset but this implies much more effort. I have no feeling if we should spent the time for such a szenario. Any opinion?
Removed usage of TypeProvider in LinkingDiagnosticMessageProvider
Added support to create local vars if expectedType is not null. The same constraint it there for field creation now. New function will take care that typeParameters are declared correctly. Regarding the errormessage Sebastian is currently working on a common solution so that we will have an other bug to enhance the errormessage after Sebastian finished his work. https://bugs.eclipse.org/bugs/show_bug.cgi?id=377775 pushed to master. Mark this as fixed.
Requested via bug 522520. -M.
