Re: [VOTE] Inner-project extension methods

[Guillaume Laforge]

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 
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  / Google+

Re: [VOTE] Inner-project extension methods

[Nathan Harvey]

What do you guys think is missing from this proposal?



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

Re: Add default methods to some interfaces in Groovy 2.6+

[Paul King]

A discussion worth having and we already do some of this, e.g. take a look
at ASTNode and NodeMetaDataHandler in master.
Just a reminder, 2.6 is still jdk7 capable. Groovy 3+ is JDK8 minimum, so
the changes would be in 3+.
For me, it's lower priority than some other things (including getting 2.5,
2.6 and 3 out the door). I think wholesale changes
of that kind would be a great refactoring for 3.1 but I'm disinclined to
have any more branches right now, so I'd hold off
for a little bit. But if there is a good reason to we can start some such
changes.

Incidentally, I did some quick fixes to get the binary compatibility report
working again late last year after it being
off for a while due to some dependency conflicts. There are some things to
fix in that report but I also
noticed that changes like the above were being flagged - methods "moved" up
the hierarchy were being flagged
as missing. Does anyone know how to hush those? Is there a setting for
japicmp?

Cheers, Paul.


On Wed, Jan 3, 2018 at 9:04 AM,  wrote:

> Now that Java 8 is the minimum required runtime, could some default
> methods be added to interfaces such as org.codehaus.groovy.ast.expr.MethodCall
> or org.codehaus.groovy.ast.Variable.  For example, predicate checks like
> isStatic(), et al. could be implemented in terms of getModifiers(), would
> provide convenience to receivers of Variable instances, and would save a
> bunch of repeated overrides in implementing classes.
>
>
>
> Can anyone think of other interfaces in core groovy that could benefit
> from default methods?
>
>
>

Add default methods to some interfaces in Groovy 2.6+

[eric.milles]

Now that Java 8 is the minimum required runtime, could some default methods be 
added to interfaces such as org.codehaus.groovy.ast.expr.MethodCall or 
org.codehaus.groovy.ast.Variable.  For example, predicate checks like 
isStatic(), et al. could be implemented in terms of getModifiers(), would 
provide convenience to receivers of Variable instances, and would save a bunch 
of repeated overrides in implementing classes.

Can anyone think of other interfaces in core groovy that could benefit from 
default methods?

RE: About adding DGM startsWith(String...) and endsWith(String...)

[eric.milles]

Isn't the trend to use CharSequence instead of String?  If it's startsWith, 
shouldn't the signature be startsWith(String one, String two, String... more) 
to avoid zero params and conflict with 1 param built-in method?

Couldn't this be just as easily expressed using the any DGM?

['prefix1', 'prefix2', ...].any { string.startsWith(it) }

Re: [VOTE] Inner-project extension methods

[Guillaume Laforge]

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  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 
> 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  / Google+