Presentation at JCrete.org

[David Alayachew]

Hello Robbe,

Thank you for your response!

I was attempting to demonstrate how, like in log4j, providing an
unsanitized input to a method and then executing it without
allowing/facilitating any context specific validations is less safe. When I
said less safe, I did not mean less safe than log4j, I meant less safe than
separating it out into 2 method calls, like I demonstrated at the end of my
email. I can see how that was confusing though, apologies.

And yes, ultimately, log4j was interpreting its inputs as a format. While
that strongly resembles a potential failure case of LOGGER template, that
was also not my intent. My intent was as simple as, put strings into a
method, fail to perform adequate validations for aforementioned reasons,
that causes problems. My point was that, when we realized that that method
required validations later on, Rémi's idea would force us to validate on
the low level inputs (etc., all mentioned in my original post) as opposed
to the generated output that immediately gets logged. I understand how this
too was unclear, apologies.

As for the Logger template, that's a really indirect way of doing things,
so much so that I'd say it's worse than my suggestions. I didn't mention it
because I think users would sooner validate on inputs or recreate the rich
object creation rather than trying to validate on a third type - template.
But even putting that aside, my point is that, by design, a Logger template
is still encouraging side-effectual code, and thus, is encouraging the
problems I mentioned in my original email. The only thing that either of
our suggestions do is provide alternative ways to not take the easy path.
But having a safe front door does not detract from the fact that there is a
(more convenient) back door. One bad apple spoils the bunch.

And finally, yes, people will value convenience over safety, as always.
Still worth calling out and criticizing when it happens -- especially when
it's not just a blog on the internet, but a full blown presentation in
front of several people that will likely color how they see this feature
and its ideal use case. I ignored his original email last time, but if he
doesn't even see what's wrong with it, then it really needs to be addressed.

Side effects are a dangerous default, and I think it's unwise to encourage
them as a default for a feature whose biggest reason for existing is making
safe interpolation convenient.

Thank you for your time!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230724/b733b2cb/attachment.htm>