<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"David Alayachew" <davidalayachew@gmail.com><br><b>To: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>Cc: </b>"Robbe Pincket" <robbepincket@live.be>, "Remi Forax" <forax@univ-mlv.fr>, "amber-dev" <amber-dev@openjdk.org><br><b>Sent: </b>Monday, July 24, 2023 4:33:19 PM<br><b>Subject: </b>Re: Presentation at JCrete.org<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div style="font-family:monospace" class="gmail_default">(looks like Brian beat me to the punch, but I'll respond anyways)<br></div><div style="font-family:monospace" class="gmail_default"><br>Hello Rémi,</div></div></blockquote><div><br></div><div>Hello,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br><br>Thank you for your response!<br><br>> A call to a template processor is a method call<br>> (processor) to a Java object (StringTemplate.Processor).<br>> If we wanted to not have side effect, instead of using a<br>> OOP design we will have used a functional design, in this<br>> case a function call with an API closer to a varargs call<br>> (similar to what JavaScript does).<br><br>Who says that OOP demands side-effects?</div></div></blockquote><div><br></div><div>I said OOP allows side effects.</div><div> 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.<br></div><div>I never said that OOP demands side-effects.<br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"></div></blockquote><div>[...]<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br><br>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.</div></div></blockquote><div><br></div><div>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.<br></div><div>Some template processors will be immutable but some will not.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>[...]<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br><br>> I believe you have missunderstood how the validation<br>> works, there is a separation between the validation of<br>> the structure and the escaping of the values.<br>> The validation of the structure can be done once while<br>> the escaping has to be done for each call.<br><br>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.<br><br>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?</div></div></blockquote><div><br></div><div>Let's take another example, a builder. I see no problem to have a template processor that acts as StringBuilder/StringJoiner.<br></div><div><br data-mce-bogus="1"></div><div>var joiner = new StringJoinerAndTemplateProcessor();<br data-mce-bogus="1"></div><div>for(...) {<br data-mce-bogus="1"></div><div> joiner."""</div><div> several lines and \{ holes }<br data-mce-bogus="1"></div><div> """;<br data-mce-bogus="1"></div><div>}<br data-mce-bogus="1"></div><div>return joiner.toString();<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I do not see why I can not to that.</div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"></div></blockquote><div>[...]<br></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br><br>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.</div></div></blockquote><div><br></div><div>Designing is about trying to separate different concerns.<br data-mce-bogus="1"></div><div>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.</div><div>Otherwise it means polutting the method signature with logging metadata like the IO monad in Haskell.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br><br>Thank you for your time!<br>David Alayachew<br></div></div></blockquote><div><br></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>