Generation of synthesized parameters

[John Rose]

On Jan 29, 2013, at 5:38 PM, Alex Buckley <alex.buckley at oracle.com> wrote:

> "visible in Java" is the wrong model. Almost anything in a class file will be "visible" to code in that class. The question is whether a construct in a class file is there because a compiler felt like implementing something in a particular way ("synthetic", and its subclass "bridge") or because a compiler was told to do it that way exactly ("synthesized").

This is a good distinction to make crisply.

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"?

"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:

connoted
covert
implicit
implied
indirect
inherent
insinuated
invisible
latent
secreted
tacit
undeclared
understood
unexpressed
veiled

For my part, I like "tacit", as in "a tacitly understood proposition", or "implicit" as used in JLS 8.8.9:
> If a class contains no constructor declarations, then a default constructor with no formal parameters and no throws clause is implicitly declared.


Almost any word other than "synthesized" would be easier to work with, for about the same reasons that you don't name distinct nearby variables "n1" and "nl".

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130129/d255e15b/attachment.html