Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Subject: Re: Extension method upgrades
To: dev@groovy.apache.org
References: <1513202990422-0.post@n5.nabble.com>
 <e3bcb8d5-91b0-5d08-b21b-0621f1e18f0d@gmx.org>
 <1513314646284-0.post@n5.nabble.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <335042eb-0a70-c99e-b898-ea36f004f9bd@gmx.org>
Date: Fri, 15 Dec 2017 08:02:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <1513314646284-0.post@n5.nabble.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
archived-at: Fri, 15 Dec 2017 07:02:16 -0000

On 15.12.2017 06:10, Nathan Harvey wrote:
> I think your first step - "define a file that contains extension functions" -
> is slightly wrong. In Kotlin, you can place extension methods anywhere, they
> do not have to be confined to a single file (or worse, like Groovy, in a
> totally different dependency). The syntax I discussed is what enables them
> to do this.

I am aware of that you can define them anywhere. But frankly, I find 
that pretty messy. I mean defining quasi global extension methods 
randomly all over the place... does sound like maintenance hell to me. 
Probably best to declare them inline as well, then you will never ever 
be able to find them again, if they are from a library.

> I'm not sure of the troubles this introduces in a dynamic context, but it
> seems your assumptions about the compiler reading in all classes then
> parsing extension methods first is likely the correct way to do it.

The trouble for the dynamic mode is, that this won`t work there.

> Maybe
> someone with more knowledge can chime in. I do think multiple conflicting
> extension methods should error in the exact same way that normal methods
> error.

Well... if there are completely bound at compile time,then the compiler 
has to do that. In Java you also have the fallback with the JVM checking 
that  for the class... Obviously that does not work for an outside of 
the class construct the JVM has no idea of.

> I think allowing extensions or "import extensions" would be a step in the
> right direction. The main technical hurdle seems to be allowing the methods
> to be declared within the same project. From there it is just syntax
> differences.

We are talking about the static compiler only, right? Because normal 
Groovy should actually be able to handle this by not caring. What I mean 
is that till runtime dynamic Groovy does barely do any method resolution 
and none that should influence extension methods. So if they are there 
or not is of no concern during compilation for dynamic Groovy. And if 
the descriptor is then on the classpath it should be able to pickup the 
extension methods at runtime. So I think this should work for normal 
Groovy and only static Groovy should have trouble here. Are weon the 
same page?

bye Jochen