Hi,
After looking at
https://kotlinlang.org/docs/reference/extensions.html#scope-of-extensions
I am actually a bit confused. You import them... and that may be done
with the star import as well.
After looking at this a bit more I noticed the following:
* you define a file that contains extension functions
* the file is compiled to a class which contains meta information about
if it contains extension methods, maybe that information is even on the
methods
* when compiling the compiler reads in all classes available and will
also extract such meta information before attempting to check method
calls and such
* this approach cannot work in a dynamic environment
* having multiple extension method holder classes of the same name must
lead to a compilation error.
With the effect, that if you have at runtime the extension methods
holder class twice on the classpath, you will get a undefined behavior
which one is taken, just as it is for all classes in this situation.
We could do the same with a class annotation, but that is about the only
declarative part we then need from a technical pint of view and this
would be compatible with what we already have.
But does it fit our needs? Would it be so bad if we had "import
extensions foo.bar.C" for example?
bye Jochen
Am 13.12.2017 um 23:09 schrieb Nathan Harvey:
Extension methods are a very powerful feature in Groovy, but they are also
difficult (and somewhat tedious) to use because they require being in
another project. I believe one reason for this limitation is the syntax of
extension methods, which are exactly the same as other methods, and so they
need to be specified as being different.
Either way, I think a huge improvement would be allowing extension methods
from within other classes on the classpath (ie not in an external
dependency). The synax for delcaring an extension method would be that of
Kotlin and other languages, for example:
public String String.upper() {
return this.toUpperCase() // "this" is bound
}
Another option would be to still have a parameter, if the "this" binding is
too confusing:
public String String.upper(String self) { ... }
Thoughts on adding these capabilities?
is abou
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
