Strings and things

[Stephen Colebourne]

Thanks for the new document. Certainly food for thought.

Putting syntax aside, the mechanism of creating an object
(TemplatedString) and delegating to an interface (TemplatingPolicy) is
perfectly reasonable given your goals. I do note a certain vagueness
in the document about exactly how the method on Connection or
ResourceBundle is defined (as the document stands, it looks like each
class can have only one associated mechanism of accepting a
TemplatedString).

I believe however that there is a missing element - pre-processing at
compile-time. There are likely to be relatively common cases where
pre-processing can be performed when returning a non-String object.
This might be for validation (eg. the SQL or JSON cases), or
optimisation (such as creating a 90% complete XML tree just waiting
for the holes to be filled in).  Not having any way to do this looks
like a missed opportunity, although what amounts to dynamic compiler
plugins would of course add complexity.

If the premise of pre-processing is accepted, it is only a relatively
small additional step to user-defined literals. Ultimately, the only
real difference is that a typical user-defined literal doesn't have
the concept of "holes".

Thus, my feedback is to question whether restricting the mechanism of
parsing the holes to the compiler is the right choice. If
`TemplatingPolicy` (or another interface) were able to parse the raw
text itself to find the holes, it could use different approaches to
find the holes, such as to look for ${} for backwards compatibility
with a previous system. Or it could just interpret the raw text as a
regex or LocalDate literal with no holes. eg. LocalDate."2021-09-16".

Stephen


On Thu, 16 Sept 2021 at 15:28, Jim Laskey <james.laskey at oracle.com> wrote:
>
> Dear amber-dev,
>
> Over on amber-spec-experts, I’ve posted a proposal for “string templates”. I
> hope people are as excited about this feature as we expect they will be.
>
> As a brief reminder, the amber-dev list is not, in general, for language
> design discussions; this list is primarily for discussion of implementation,
> bug repoorts, experience reports, etc.  We should let the experts do their
> job without having to follow parallel discussions on multiple lists.
>
> If people want to post brief, reasoned feedback on the approach,
> applicability, or usefulness (but *NOT* the syntax) of the proposal here,
> that would be fine. Please, let’s keep it constructive.
>
> Cheers,
>
> -- Jim
>
>