Proposal: @NamedParameters AST transform

classic Classic list List threaded Threaded
15 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: @NamedParameters AST transform

Jochen Theodorou
first of all, please note this mailing list may close any time now. Thus
we better continue on [hidden email]

So are there plans to support JEP 118 (named parameters in Java) in Groovy?

Not yet. There are a few problems to solve (you can help there).

1) Availability:
named parameters are available only in JDK8 bytecode. This means
bytecode like that will be rejected by earlier JDKs. The JDK itself is
not compiled with support for named parameters and you need a special
command line switch (again only JDK8+) for javac to enable it.

2) Compatibility with old logic
The old logic is map based. There is no information about parameter
names that we could use to write into the class file using the old logic
because of that. The JDK8 logic does not easily allow optional arguments
with default values, you have to obey the same rules as normal
parameters with default arguments here, which means it is more limiting.
The incompatibility means the new named parameters could not just
replace the old version. But then how to solve it?

3) method call and selection logic
it will make the method selection logic much more difficult, since then
there is no rule for positioning arguments anymore. Before the
programmer did do this more or less, with the disadvantage of for
example never getting primitives directly (and paying for the cost) and
of course the map overhead (and paying again with method hotspot cannot
inline easily) - but at least the method selection logic itself was not
affected by named parameters and could concentrate on the positional
types. Changing this will require bigger changes in the runtime. And
given that the MOP is just using an Object[] in several positions, there
will be the question of how to transport the "name" information of the
argument as well.

Please note: I am not saying we should not do this or we should. I am
not saying bad  or good idea. I am just pointing out some of the things
we have to think about when talking about JEP 118.

Of course we could also do it similar to Java with the following...
*) ignore named parameters in our method call logic and stay with the
map version
*) use a command line switch (compiler configuration option) to write
the named argument to bytecode and force jdk8 level bytecode.

bye blackdrag


Am 11.05.2015 05:53, schrieb nickgrealy:

> Hi all,
>
> Given that  JDK8 now supports accessing named parameters at runtime
> <http://openjdk.java.net/jeps/118>  , are there any plans to incorporate
> this into Groovy?
>
> I've following up/posting this question on related(?) threads " Methods
> parameters names
> <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=edit_post&node=5723458>
> " and " Proposal: @NamedParameters AST transform
> <http://groovy.329449.n5.nabble.com/Proposal-NamedParameters-AST-transform-td5156566.html>
> ". (Are there any more recent threads?)
>
> Kind regards,
>
> Nick Grealy
>
>
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/Proposal-NamedParameters-AST-transform-tp5156566p5723459.html
> Sent from the groovy - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>


--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: @NamedParameters AST transform

nickgrealy
Hi Blackdrag,

Thanks for your response. I tried replying to your "hidden email address" but got the following error: "Domain starts with dot. Please fix the error and try again."

I'd love to help out anyway I can, if you can point me in the right direction, that'd be great.

I'm primarily interested in using the parameter name's in a "refelection" manner, so that I can programmatically generate documentation, etc at runtime.

Re: Using named parameters for method invocation - I like the way groovy currently handles named parameters, I wouldn't propose changing the current behaviour.

1) Availability:

As you said, the jdk8 named parameters are available in the compiled bytecode, which is not backwards compatible. I don't see this as a problem, as long as it's well documented. We could also use the "-parameters" compiler command line parameter. What're your thoughts?

2) Compatibility with old logic 

I haven't actually looked through the Groovy compiler's code, to determine how it stores "method" metadata, and what limitations there are (in regards to retrieving parameter names). Where can I learn more about the groovyc compiler/contributing?

3) method call and selection logic

This would be a tricky to change (for the reasons you identified), but could benefit from the availability of parameter names. I'm not really interested in changing this behaviour however.

Where to from here?
- which forum/where should we be discussing these changes?
- how do these changes get approved?
- is there a feature/issue tracking system (in github?)

Thanks, Nick

P.S.

Incidently, I tried to the join the new apache mailing list, but was rejected because I don't have a @apache.org email address.

"Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<users@groovy.apache.org>:
Must be sent from an @apache.org address or a subscriber address or an address in LDAP."

Do you know who could look at this? Am I doing something wrong?
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: @NamedParameters AST transform

nickgrealy
In reply to this post by Jochen Theodorou
Ignore my questions about contributing, I'm reading up on - http://www.groovy-lang.org/contribute.html#code
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: @NamedParameters AST transform

Jochen Theodorou
In reply to this post by nickgrealy
Am 11.05.2015 07:41, schrieb nickgrealy:
> Hi Blackdrag,
>
> Thanks for your response. I tried replying to your "hidden email address"
> but got the following error: "Domain starts with dot. Please fix the error
> and try again."

ah, ok, nabble did hide the address... it was users at
groovy.incubator.apache.org. You can subscribe sending a message to
users-subscribe at groovy.incubator.apache.org

> I'd love to help out anyway I can, if you can point me in the right
> direction, that'd be great.
>
> I'm primarily interested in using the parameter name's in a "refelection"
> manner, so that I can programmatically generate documentation, etc at
> runtime.
>
> Re: Using named parameters for method invocation - I like the way groovy
> currently handles named parameters, I wouldn't propose changing the current
> behaviour.

ok, in that case it is more easy... will force jdk8 though.

> *1) Availability:*
>
> As you said, the jdk8 named parameters are available in the compiled
> bytecode, which is not backwards compatible. I don't see this as a problem,
> as long as it's well documented. We could also use the "-parameters"
> compiler command line parameter. What're your thoughts?

I would prefer a more descriptive name, but that's something that can be
still discussed. No sweating there.

> *2) Compatibility with old logic*
>
> I haven't actually looked through the Groovy compiler's code, to determine
> how it stores "method" metadata, and what limitations there are (in regards
> to retrieving parameter names). Where can I learn more about the groovyc
> compiler/contributing?

the compiler is actually a quite complex beast. For this change, you
would have to get to know, how to emit bytecode to write out this
information using the asm lib and then add it to
AsmClassGenerator#visitConstructorOrMethod. To get an idea about how to
do this, you can use the asm lib tools to "decompile" a java class into
a piece of asm using code.

See

http://asm.ow2.org/
http://asm.ow2.org/doc/faq.html#Q10
http://download.forge.objectweb.org/asm/asm4-guide.pdf

[...]
> Where to from here?
> - which forum/where should we be discussing these changes?

dev at groovy.incubator.apache.org is the developer list. I think it is
best to discuss there about the implementation details.

> - how do these changes get approved?
> - is there a feature/issue tracking system (in  github
> <https://github.com/apache/incubator-groovy>  ?)

since your proposal is not changing the language and only targets adding
additional reflective information as well as a new command line switch /
compiler configuration I think it is enough if you make a pull request
at github and any of the committers will merge it.

[...]
> P.S.
>
> Incidently, I tried to the join the new apache mailing list, but was
> rejected because I don't have a @apache.org email address.
 >
> "Hi. This is the qmail-send program at apache.org.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
>
> <[hidden email]>:
> Must be sent from an @apache.org address or a subscriber address or an
> address in LDAP."
>
> Do you know who could look at this? Am I doing something wrong?

two mistakes... groovy.incubator.apache.org is the right server. We are
not a top level project yet, so there has to be the incubator part in
there. And next is that you have to append -subscribe to the list name.
In to total users-subscribe at groovy.incubator.apache.org

Though for implementation details and such dev at
groovy.incubator.apache.org would be better.

bye blackdrag

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Proposal: @NamedParameters AST transform

nickgrealy
12