[VOTE] Inner-project extension methods

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Inner-project extension methods

Nathan Harvey
I'm starting a vote to add the ability to declare extension methods within
the same project that they are used, removing the requirement to isolate
them to a separate/external dependency. More discussion here:
http://www.groovy-lang.org/mailing-lists.html#nabble-f372993

One question left remaining is the syntax for declaring the extension
methods. I think the best option, at least to start out with, is to use an
annotation. For example:

@Extension
public String upper(String self) { ... }

This follows existing paradigms and doesn't introduce any new syntax. The
possible downside is a hit to IDE performance because it relies on
annotations. In theory, once the ability to declare extensions within the
project exists, this can be managed much more easily, and another vote could
be had to decide the best syntax.

Please vote on adding the new feature to Apache Groovy 3.0.0 and 2.6.0
releases.

[ ] +1  The feature sounds good
[ ]   0  I don't have a strong opinion about this, but I assume it's ok
[ ]  -1  Because...

PS this is the first vote I've called, hopefully I did everything right.
Thanks to Daniel for helping me out.



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
MG
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

MG
Non-PMC +1, purely from a Groovy user's perspective...

On 31.12.2017 04:51, Nathan Harvey wrote:

> I'm starting a vote to add the ability to declare extension methods within
> the same project that they are used, removing the requirement to isolate
> them to a separate/external dependency. More discussion here:
> http://www.groovy-lang.org/mailing-lists.html#nabble-f372993
>
> One question left remaining is the syntax for declaring the extension
> methods. I think the best option, at least to start out with, is to use an
> annotation. For example:
>
> @Extension
> public String upper(String self) { ... }
>
> This follows existing paradigms and doesn't introduce any new syntax. The
> possible downside is a hit to IDE performance because it relies on
> annotations. In theory, once the ability to declare extensions within the
> project exists, this can be managed much more easily, and another vote could
> be had to decide the best syntax.
>
> Please vote on adding the new feature to Apache Groovy 3.0.0 and 2.6.0
> releases.
>
> [ ] +1  The feature sounds good
> [ ]   0  I don't have a strong opinion about this, but I assume it's ok
> [ ]  -1  Because...
>
> PS this is the first vote I've called, hopefully I did everything right.
> Thanks to Daniel for helping me out.
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

paulk_asert
In reply to this post by Nathan Harvey
I'm happy to help flesh out the idea but for me the devil is in the detail and I'd reserve my vote until some more detail is available. Regardless of any kind of voting, there is nothing stopping anyone from creating something like the Extension annotation you mention. The trick is going to be how to define the extension which might need information only available in later stages of compilation and then make that available during compilation and perhaps needed at an earlier phase to be applied properly.

Cheers, Paul.

On Sun, Dec 31, 2017 at 1:51 PM, Nathan Harvey <[hidden email]> wrote:
I'm starting a vote to add the ability to declare extension methods within
the same project that they are used, removing the requirement to isolate
them to a separate/external dependency. More discussion here:
http://www.groovy-lang.org/mailing-lists.html#nabble-f372993

One question left remaining is the syntax for declaring the extension
methods. I think the best option, at least to start out with, is to use an
annotation. For example:

@Extension
public String upper(String self) { ... }

This follows existing paradigms and doesn't introduce any new syntax. The
possible downside is a hit to IDE performance because it relies on
annotations. In theory, once the ability to declare extensions within the
project exists, this can be managed much more easily, and another vote could
be had to decide the best syntax.

Please vote on adding the new feature to Apache Groovy 3.0.0 and 2.6.0
releases.

[ ] +1  The feature sounds good
[ ]   0  I don't have a strong opinion about this, but I assume it's ok
[ ]  -1  Because...

PS this is the first vote I've called, hopefully I did everything right.
Thanks to Daniel for helping me out.



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

Guillaume Laforge
Administrator
Same as Paul here.
I'd be curious to see it fleshed out more.
We've been discussing something like this on and off for a long time, and I think this might be a nice addition.

On Tue, Jan 2, 2018 at 1:40 AM, Paul King <[hidden email]> wrote:
I'm happy to help flesh out the idea but for me the devil is in the detail and I'd reserve my vote until some more detail is available. Regardless of any kind of voting, there is nothing stopping anyone from creating something like the Extension annotation you mention. The trick is going to be how to define the extension which might need information only available in later stages of compilation and then make that available during compilation and perhaps needed at an earlier phase to be applied properly.

Cheers, Paul.

On Sun, Dec 31, 2017 at 1:51 PM, Nathan Harvey <[hidden email]> wrote:
I'm starting a vote to add the ability to declare extension methods within
the same project that they are used, removing the requirement to isolate
them to a separate/external dependency. More discussion here:
http://www.groovy-lang.org/mailing-lists.html#nabble-f372993

One question left remaining is the syntax for declaring the extension
methods. I think the best option, at least to start out with, is to use an
annotation. For example:

@Extension
public String upper(String self) { ... }

This follows existing paradigms and doesn't introduce any new syntax. The
possible downside is a hit to IDE performance because it relies on
annotations. In theory, once the ability to declare extensions within the
project exists, this can be managed much more easily, and another vote could
be had to decide the best syntax.

Please vote on adding the new feature to Apache Groovy 3.0.0 and 2.6.0
releases.

[ ] +1  The feature sounds good
[ ]   0  I don't have a strong opinion about this, but I assume it's ok
[ ]  -1  Because...

PS this is the first vote I've called, hopefully I did everything right.
Thanks to Daniel for helping me out.



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html




--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

Nathan Harvey
In reply to this post by Nathan Harvey
What do you guys think is missing from this proposal?



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

Guillaume Laforge
Administrator
Things like expliciting the scope: what's the scope of those extensions?
If it's on the classpath, it applies everywhere?
And with Java 9 modules, does it change something in terms of scope?

In the past we've talked about lexical extensions, in the sense that you had to import those methods so that they could be applied to the local source file.
Imagine something like import extension com.foo.StringExt.startsWithAny (a bit like static import of methods)
We could also have an annotation on a per-method level that says that a particular extension applies to just the scope of that method.
Should(n't) we consider something like this too? 
Pros/cons of different approaches?

Still on scope, the categories, the extensions applies to any code that was running inside the scope of the use {}:
anything that was called like foo() calls bar() calls baz() from other classes not in the current class or script also had these extensions applied.
Here, are we just speaking of the scope of the source file, and not what's being called from there? (which I think I'd prefer anyway)

We can still discuss the syntax, but I'd be interested in seeing one.
Although you can start experimenting with an AST transformation.

On principle, I think I'm in favor of the idea, but as Paul said in another thread, the devil is always in the details!

Guillaume


On Wed, Jan 3, 2018 at 3:04 AM, Nathan Harvey <[hidden email]> wrote:
What do you guys think is missing from this proposal?



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

Jochen Theodorou
On 03.01.2018 07:44, Guillaume Laforge wrote:
[...]
> We can still discuss the syntax, but I'd be interested in seeing one.
> Although you can start experimenting with an AST transformation.
>
> On principle, I think I'm in favor of the idea, but as Paul said in
> another thread, the devil is always in the details!

An AST transformation is not going to be enough for a full dynamic
version. Just look at the continuous problems we have with static
imports. The transform can then not be more as a simple showcase with a
naive implementation. The actual implementation will differ - a lot.

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

Guillaume Laforge
Administrator
Fair point, Jochen.

On Wed, Jan 3, 2018 at 10:06 AM, Jochen Theodorou <[hidden email]> wrote:
On <a href="tel:03.01.2018%2007" value="+33301201807" target="_blank">03.01.2018 07:44, Guillaume Laforge wrote:
[...]
We can still discuss the syntax, but I'd be interested in seeing one.
Although you can start experimenting with an AST transformation.

On principle, I think I'm in favor of the idea, but as Paul said in another thread, the devil is always in the details!

An AST transformation is not going to be enough for a full dynamic version. Just look at the continuous problems we have with static imports. The transform can then not be more as a simple showcase with a naive implementation. The actual implementation will differ - a lot.

bye Jochen



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

Nathan Harvey
In reply to this post by Guillaume Laforge
This idea is unrelated to categories. The behavior would be identical to
current extension methods, except you can use them within the same project.
No special importing or scoping required, just as it works currently.
Hopefully that answers most of the questions you have. I don't know about
how it would work with Java 9.

I am personally against an "import extension" strategy because of the
difficulties it would probably introduce for IDEs. Consider you've added a
String extension method, but it's not marked with anything in particular,
because you can just "import extension." If you start typing the method
name, it has no idea which method could be used as an extension. Basically,
there has to be some indicator on the declaring method, which makes "import
extension" useless IMO.



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Inner-project extension methods

Jochen Theodorou
On 03.01.2018 19:56, Nathan Harvey wrote:
> This idea is unrelated to categories. The behavior would be identical to
> current extension methods, except you can use them within the same project.
> No special importing or scoping required, just as it works currently.

just as it works currently is that a service provider like structure is
used. As things are already compiled once the dynamic code takes notice
of extension methods, this means to me, that there is nothing to do here
for normal Groovy.

In my opinion we are then more talking about a "bugfix" for the static
compiler.

> Hopefully that answers most of the questions you have. I don't know about
> how it would work with Java 9.

equally bad :(

> I am personally against an "import extension" strategy because of the
> difficulties it would probably introduce for IDEs. Consider you've added a
> String extension method, but it's not marked with anything in particular,
> because you can just "import extension." If you start typing the method
> name, it has no idea which method could be used as an extension. Basically,
> there has to be some indicator on the declaring method, which makes "import
> extension" useless IMO.

the method would still have to be a static method with the this/self
parameter being the first one and defining the type. If that is solved
for normal extension methods and/or categories, then there should be no
problem for the IDE.

bye Jochen
12