Feedback: String Templates (JEP 430)

[Brian Goetz]

>>
>>>
>>> ... but while we're here, the entire of method seems pointless. 
>>> After all, Processor is, itself, a functional interface, so we can 
>>> just delete the `StringTemplate.Processor.of()` part of the above 
>>> snippet and it would exactly the same way!
>>>
>>
>> This whole section seems an unnecessary detour, and kind of a big 
>> distraction.
>
> I felt it necessary ...

Yes, of course by "this is a big distraction", I really meant "let's 
spend a lot more time on it" :)

> In that sense, records were very slightly non-culture-compatible: 
> |LocalDate.getYear()| now stands out as somewhat weird:

Yes, and this was a carefully considered decision.  In the end we 
decided against doubling down on the mistakes of the past, which means 
that some old code now looks, well, old.  That doesn't mean we're in a 
hurry to do this every time, but in the right situations, it is a move 
we can sometimes justify.

> In that sense, it is odd that string processors have 
> checked-exception-as-a-type-var when |j.u.Function| interfaces don’t.

Sorry, I disagree with this (which is why I tried to prune this 
direction.)  We considered the role of exceptions in Function and 
friends, and we considered the role of exceptions in ST.Processor, and 
because each context was different, we came to different answers for 
different interfaces.  And that's OK!  Because functional interfaces 
were designed to work with or without exceptions.  This is not any sort 
of "glaring inconsistency", just the result of a process that requires 
contextual judgement being applied in different contexts.

> Removing it from Processor is the most obvious way to tackle that 
> incongruence.

IMO this is the kind of "consistency" that certain kinds of hobgoblins 
are attracted to :)

>
>>>
>>> ## Compile time checking
>>>
>>
>> Definitely a different topic :)
>>
>
> The idea that I can type |REGEX.”(foo)+bar”| and get compile-time 
> validation of the regex, and perhaps even compile-time construction of 
> a thompson-NFA style tree so that the regex loads and runs faster at 
> runtime (shift some of the ‘work’ to compile-time) is /very/ exciting, 
> though 😉

Yes, it is.  And I understand why it is tempting to want to backdoor 
some of that in through this feature, but this is not how we're going to 
get to a consistent and grounded form of compile-time evaluation.  So 
that will have to wait until we can do it right.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230331/6b152ffa/attachment-0001.htm>