You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Nathan Harvey <na...@gmail.com> on 2017/12/31 03:51:17 UTC
[VOTE] Inner-project extension methods
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
Re: [VOTE] Inner-project extension methods
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <pa...@asert.com.au> 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 <na...@gmail.com>
> 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
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE] Inner-project extension methods
Posted by Paul King <pa...@asert.com.au>.
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 <na...@gmail.com>
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
>
Re: [VOTE] Inner-project extension methods
Posted by Guillaume Laforge <gl...@gmail.com>.
Fair point, Jochen.
On Wed, Jan 3, 2018 at 10:06 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> 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
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE] Inner-project extension methods
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: [VOTE] Inner-project extension methods
Posted by Nathan Harvey <na...@gmail.com>.
Hi guys, I'm still very much hoping this feature can be added. Again I don't
know the technical details necessary but hopefully some more conversation
can take place.
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Inner-project extension methods
Posted by Jochen Theodorou <bl...@gmx.org>.
On 04.01.2018 13:44, Jochen Theodorou wrote:
> 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.
The relevant code entry point can be found in
StaticTypeCheckingSupport:2167. The ExtensionModuleScanner tries to load
the extensions classes as classes, which cannot work if they are not yet
compiled. getDGMMethods has to be changed as well. Maybe there are also
changes to StaticCompilationVisitor required.
bye Jochen
Re: [VOTE] Inner-project extension methods
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: [VOTE] Inner-project extension methods
Posted by Nathan Harvey <na...@gmail.com>.
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
Re: [VOTE] Inner-project extension methods
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <na...@gmail.com>
wrote:
> What do you guys think is missing from this proposal?
>
>
>
> --
> 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
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE] Inner-project extension methods
Posted by Nathan Harvey <na...@gmail.com>.
What do you guys think is missing from this proposal?
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Inner-project extension methods
Posted by MG <mg...@arscreat.com>.
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
>