Presentation at JCrete.org

[David Alayachew]

Hello Rémi,

Thank you for your response!

>Having a template processor that returns Void is fine.

The entire point of the Template Processor is to produce something. That's
even more fundamental to its goal than the point about safety. You are
trying to turn this into side-effect machine because you can, and I'm
telling you that that is a bad use of the tool because of all the reasons
I've mentioned above.

> 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.

This is so much worse than the logger template, Rémi. At least with the
logger one, it was only side-effects. Now you want to add state that the
processor takes with it. And the only benefit you get is that you get to
save a few key strokes per append(). There are so many ways around this
without having to depend on carrying state between calls.

This feels like to me that you want to make all sorts of Template
Processors that do what existing libraries do, but as a template processor.
The entire purpose of this api is supposed to be for interpolation, and I
think Brian put it even better by thinking of it as a factory.

Thank you for your time!
David Alayachew



On Mon, Jul 24, 2023 at 11:50 AM <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"David Alayachew" <davidalayachew at gmail.com>
> *To: *"Brian Goetz" <brian.goetz at oracle.com>
> *Cc: *"Robbe Pincket" <robbepincket at live.be>, "Remi Forax" <
> forax at univ-mlv.fr>, "amber-dev" <amber-dev at openjdk.org>
> *Sent: *Monday, July 24, 2023 4:33:19 PM
> *Subject: *Re: Presentation at JCrete.org
>
> (looks like Brian beat me to the punch, but I'll respond anyways)
>
> Hello Rémi,
>
>
> Hello,
>
>
>
> Thank you for your response!
>
> > A call to a template processor is a method call
> > (processor) to a Java object (StringTemplate.Processor).
> > If we wanted to not have side effect, instead of using a
> > OOP design we will have used a functional design, in this
> > case a function call with an API closer to a varargs call
> > (similar to what JavaScript does).
>
> Who says that OOP demands side-effects?
>
>
> I said OOP allows side effects.
> In fact, one nice feature of OOP is to be able to distangle the different
> side effects on an application, i.e to have side effects but in a
> controlled/organized way.
> I never said that OOP demands side-effects.
>
> [...]
>
>
>
> Each template processor has its own template, which doesn't change. All it
> does is take in the arguments, interpolates them either as pre-configured,
> or as the developer configured it to, then returns the specified output.
> And since all of the input arguments are just there to construct a larger
> object, no side-effects are necessary! It's not until you start trying to
> execute log statements that side-effects enter, and that's what I am taking
> issue with.
>
>
> I respectfully disagree, a template processor is an instance of a class,
> so values comes from the class itself, the template fragments and the
> template values.
> Some template processors will be immutable but some will not.
>
> [...]
>
>
>
> > I believe you have missunderstood how the validation
> > works, there is a separation between the validation of
> > the structure and the escaping of the values.
> > The validation of the structure can be done once while
> > the escaping has to be done for each call.
>
> After reading Robbe's comment (and rereading mine), I realize it was a
> mistake to use log4j as an example. I was trying to speak way more
> generally than everyone else interpreted it to be. I would encourage you to
> reread my response to Robbe to better understand what I truly meant.
>
> But in short, my point was, each use site has different validation needs.
> And to use the correct terminology here, I mean validating that the value
> created after escaping is good and safe. If you make a template processor
> that not only creates the output from the given inputs, but also uses that
> output to perform a state-changing side-effectual action, then you make it
> harder, not easier, to validate that the output generated in the first
> place was correct. And since one of the biggest points of this feature is
> to make safe-interpolation easy, your example flies in the face of what
> this JEP is trying to do. Does that make sense why I am taking so much
> issue with your idea?
>
>
> 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.
>
> [...]
>
>
>
> It's fine to criticize the performance and the way that the template
> processor handles its internals. But those reasons are not the biggest
> reason why a Logger template would be a bad idea. The biggest reason is
> because of the side-effects that you are bringing front and center. OOP has
> nothing to do with it. You are turning something that can and should be a
> pure functional call into some state-modifying and side-effectual, and that
> is the core problem with your logger template. That is the entire point I
> was trying to make.
>
>
> Designing is about trying to separate different concerns.
> Logging something has to return void / do side effects, because logging is
> a separate concern from the goal of the method which contains the logging
> statement.
> Otherwise it means polutting the method signature with logging metadata
> like the IO monad in Haskell.
>
> Having a template processor that returns Void is fine, exactly like having
> a template processor that throws an exception is fine (the API even allow
> checked exceptions).
>
>
>
> Thank you for your time!
> David Alayachew
>
>
> Rémi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230724/aff09637/attachment.htm>