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
