A small patch to use the StringConcatFactory instead of String.format() to implement toString() of a data class

[forax at univ-mlv.fr]

The other solution, the one i currently use for this kind if problem, is to use a ClassValue, but injecting values into a ClassValue is not very beautiful and you have less sharing at bytecode level. 

Rémi 

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Vicente Romero"
> <vicente.romero at oracle.com>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Mardi 14 Novembre 2017 14:57:31
> Objet: Re: A small patch to use the StringConcatFactory instead of
> String.format() to implement toString() of a data class

> On Nov 14, 2017, at 4:40 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>> Speaking of the meta protocol, i wonder if at some point, it's not better to use
>> a condy to encapsulate the data class, the field names and the getters. So the
>> runtime representation that split the names and create the unmodifiable lists
>> can be shared between the 3 invokedynamic calls.

> Yes! That's a driving motivation for condy, to manage the ad hoc
> metadata required by a modern translation strategy.

> We came across that use case thinking about enhanced switch,
> where each case probably wants to have its own metadata
> block which reifies all the pattern-matching logic for the case.
> Then the switch as a whole is an indy whose arguments are
> those cases. This is also why we are lifting arity limitations on
> BSM argument lists.

> — John