Generation of synthesized parameters
John Rose
john.r.rose at oracle.com
Wed Jan 30 18:48:54 PST 2013
On Jan 30, 2013, at 1:19 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> "implicit" is a fine choice for these constructs _in the JLS_. JLS8 will use this term more widely and consistently.
Yay!
> However, the construct is physically present in the class file, so I feel "implicit" is not right for the JVMS.
Good. I suggested "implicit" only because the JLS uses that term. The word has a lot of extra conceptual baggage. (Cf. Scala implicits.)
> (We may one day want "implicit" for truly auto-magical JVM constructs like local variable #0 representing the receiver. We should avoid s/synthesized/implied/ now since we'd be setting up for "implied" and "implicit"!)
Yes.
> The key concept is that a construct is in the class file because some other specification wanted it there. The construct is inessential to the JVM itself. "tacit" implies the JVM cares about the construct, and will do something useful with it, but in fact the JVM just passes the construct through to higher-level entities such as core reflection.
Not sure I follow this objection to "tacit", but maybe that's because I'm thinking from the Core Reflection POV instead of the JVM POV.
> I'm leaning towards "mandated".
Yes, I think that is a very workable choice. Far better than implicit or synthesized.
Thanks,
— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130130/78f02ca4/attachment.html
More information about the compiler-dev
mailing list