Generation of synthesized parameters

[Alex Buckley]

On 1/29/2013 9:17 PM, John Rose wrote:
> And, the words used to formulate the distinctions matter.  So, aren't we
> going to get endless confusion because of the near identity (as words)
> of the two terms "synthetic" and "synthesized"?

I think semantic explanations of the two (strongly related) concepts get 
people 90% of the way there - but for a quiet life I will concede the 
words are depressingly similar.

> "Synthetic" is a given, probably, having been there since 1.1.  (My
> coinage, as it happens.)
>
> But do we really have to call the other "synthesized"?  (Does the
> bikeshed have to be painted so people mistake it for the toolshed?)
>
> How about something moderately descriptive but completely different from
> "synthetic", like any of:

"implicit" is a fine choice for these constructs _in the JLS_. JLS8 will 
use this term more widely and consistently. However, the construct is 
physically present in the class file, so I feel "implicit" is not right 
for the JVMS.

(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"!)

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.

I'm leaning towards "mandated".

Alex