Presentation at JCrete.org

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "David Alayachew"
> <davidalayachew at gmail.com>
> Cc: "Robbe Pincket" <robbepincket at live.be>, "amber-dev" <amber-dev at openjdk.org>
> Sent: Monday, July 24, 2023 6:02:16 PM
> Subject: Re: Presentation at JCrete.org

>> Let's take another example, a builder. I see no problem to have a template
>> processor that acts as StringBuilder/StringJoiner.

>> var joiner = new StringJoinerAndTemplateProcessor();
>> for(...) {
>> joiner."""
>> several lines and \{ holes }
>> """;
>> }
>> return joiner.toString();

>> I do not see why I can not to that.

> I am sorry to hear this. This is a needlessly-bad design.

> The invocation of ."..." has an effect, but there is no verb visible. What does
> it do? (I am not looking for an answer; the fact that I have to ask makes this
> a terrible API design.)
I know that you are playing the devil advocate here but given that the variable is called joiner, you may think, occasionnally, that a joiner may join. 

Anyway, you convince me one year ago that using an interface instead of a function call was a better idea in term of syntax, but now you are saying that the semantics is not the usual semantics on a method call on an interface. I think i've the right to be confused. 

> Whereas, when TemplateProcessor behaves more like Function, it is clear what it
> does; takes an X, and gives me a Y. (It is then on me to handle the Y
> properly.)
Some template processors are like a Function, like RAW, but for example, FMT is an instance of a real class, FormatProcessor. 

[...] 

> I think it is probably time to end this conversation here, though; further
> arguing about "I wish the design center of this feature were different" doesn't
> seem counterproductive, and it seems you are pretty much there.

I do not whish the design center of this feature to be different*. 
I'm trying to figure out why you think that having a template processor that do side effects is a bad idea. 

Rémi 

* I may think that the runtime implementation can be simplified by removing j.l.r.Carriers and friends, and make Processor.Linkage open. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230724/e56642ea/attachment-0001.htm>