> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "John Rose" <john.r.r...@oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Sent: Mardi 2 Novembre 2021 18:43:29
> Subject: Translation musings (was: Are templated string embedded expressions
> "method parameters" or "lambdas"?)
> 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.
Templated strings can have a awful performance model if we are not careful, and
i don't think that relying on the user being careful aka the C++ strategy is a
good strategy.
They have been enough lengthy discussions about the performance of
String.format() vs StringBuilder, i think it's reasonable to avoid to create
new performance pot holes when designing this feature.
So static validation and being indy-based are a little more than just nice to
have, they are here to provide an easy to understand performance model.
regards,
Rémi
