Re: [VOTE] Inner-project extension methods

[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

[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>