groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Extension method upgrades
Date Thu, 14 Dec 2017 13:10:46 GMT
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
> 

Mime
View raw message