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 <[email protected]> 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 >
