Presentation at JCrete.org

[David Alayachew]

I'm sending this message to notify that I'm continuing this thread off of
the amber-dev list. If anyone wants to be included/excluded, please reach
out individually to me. And please DO NOT CC OR RESPOND TO AMBER DEV.

On Mon, Jul 24, 2023 at 1:02 PM <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *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/4c285718/attachment.htm>