Translation musings (was: Are templated string embedded expressions "method parameters" or "lambdas"?)
Brian Goetz
brian.goetz at oracle.com
Tue Nov 2 17:43:29 UTC 2021
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>
More information about the amber-spec-experts
mailing list