Community
Participate
Working Groups
Some existing frameworks (Play!) require declaration of static methods, also Java requires a static main to start a process. We should allow having that in Xtend.
*** Bug 363578 has been marked as a duplicate of this bug. ***
I've pushed an initial version to 'master'. please review.
(In reply to comment #2) > I've pushed an initial version to 'master'. please review. I'm guessing that things pushed to 'master' can be tested by using the nightly update site?(Well if it's nightly, that means I can test it tomorrow using the nightly??)
(In reply to comment #3) > (In reply to comment #2) > > I've pushed an initial version to 'master'. please review. > > I'm guessing that things pushed to 'master' can be tested by using the nightly > update site?(Well if it's nightly, that means I can test it tomorrow using the > nightly??) that's right, here you can see which nightly build includes which changes: https://hudson.eclipse.org/hudson/job/Xtext-nightly-HEAD/changes
Looks very good. The static methods should be available as extension methods as well.
(In reply to comment #5) > Looks very good. The static methods should be available as extension methods as > well. fixed.
(In reply to comment #5) > Looks very good. The static methods should be available as extension methods as > well. I think it would be more consistent if we only did this for Xtend, wouldn't it?
Indeed. Sorry Moritz for not pointing that out.(In reply to comment #7) > (In reply to comment #5) > > Looks very good. The static methods should be available as extension methods as > > well. > > I think it would be more consistent if we only did this for Xtend, wouldn't it? Indeed. Sorry, Moritz, for not pointing that out earlier.
In fact (Sebastian already suggested that) if you use Junit 3, and therefore have Assert in your hierarchy you'll get all assert methods proposed as extension methods. That's not so nice. Although it seems a bit asymmetrical I'm in favor of not having the static methods being put on the scope as extension methods. If people want to have them they can use a static extension import.
The static methods from the very same class should be on the extension scope, shouldn't they? But we should require an explicit static extension import for the 'inherited' static methods.
As also the local class can be used in a static extension import, we can completely rely on this for static extensions.
I've applied the following changes to 'master': - static methods are not implicitly available as extension methods. Instead, a "import static extension" is required. - added tests for scoping and validation in case of referenced invisible static members.
The contents of the scopes looks bogus to me for static contexts, e.g. def static foo() { equals(new Object()) } yields 'Couldn't resolve reference equals(..)' instead of 'Cannot refer to instance member in static context'.
Static dispatch methods should be possible too. And we should have validation error if not all dispatch functions are either static or not.
(In reply to comment #13) > The contents of the scopes looks bogus to me for static contexts, e.g. > > def static foo() { > equals(new Object()) > } > > yields 'Couldn't resolve reference equals(..)' instead of 'Cannot refer to > instance member in static context'. fixed: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=4f52951224af32b806315eaa056c35825e8feb61 (In reply to comment #14) > Static dispatch methods should be possible too. > > And we should have validation error if not all dispatch functions are either > static or not. fixed: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=dad24be43df84097c9efe3bab4194f25b7ba1b9a all fixed went to 'master'. When writing tests I noticed that our syntactic sugar to treat set-method-invocations as assignments e.g. --- class X { def static setFoo(String x) {} def meth() { foo = '' } } --- doesn't work (failure during linking). Design-wise I'd prefer to keep it this way, since good coding style suggests that static methods are pure methods. Invoking a method using assignment-syntax, however, looks like the assigned state is going to be kept somewhere, i.e. the method is not pure. Expressed differently, foo = 1 with foo being static only makes sense if setFoo(int) sets a global singleton value.
That's ok for now.
Closing all bugs that were set to RESOLVED before Neon.0
