Translation musings (was: Are templated string embedded expressions "method parameters" or "lambdas"?)

[Brian Goetz]

I think we need to redirect a bit.

> I’m pointing out a different proposition:  *If* you need static 
> validation of a string, *then* you need something constant about the 
> receiver.  By constant I mean, very specifically, “fixed no later than 
> just before the first execution of of the string template expression”. 
>  The “something constant” might be the type (some subtype of a known 
> “ST-Handler”), or it might be a constant value (e.g., a static final 
> field value).

And I'm saying something different:

  - We never *need* static validation of the string.
  - We never *need* an indy-based, multi-step translation.

Both of these are nice to haves, not must-haves; the goal is to extract 
these when we can have them, not to restrict the feature so that we 
can't use the feature if we can't produce them.

We are in deep danger of way over-rotating towards the translation. I 
would go as far as to say that if we always, now and for the forever 
future, just translated with "invokeinterface", it would *still* be a 
successful and popular feature.  Do we want to do better when we can?  
Of course.  Are we willing to restrict the feature to the cases where 
can do so?  Absolutely not.

It's really easy to get wrapped around the axle over cases like 
String::format, and convince ourselves that this is the 99% use case.  
But this represents only a slice (yes, an important slice) of the 
benefits we get from this feature.  In many cases, the work we'll do to 
translate the template (e.g., a CLASS."public class Foo { ... }" policy) 
or after we translate the template (execute a SQL query) completely 
dominates the performance profile.

So yes, let's optimize for the best-case translation when we can, but 
let's not let that constrain what feature we deliver.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20211102/3372bdb9/attachment.htm>