A couple questions about String Templates

Mon Oct 23 14:53:13 UTC 2023

Some more thoughts about delegating processors.

The image that just started bumping around in my head was that of inner
classes.

If I wanted to solve this type of problem with normal Java, the first thing
I would think of would be to do it with inner classes. It would not be the
iron clad guard rails I am looking for, but it would be a clear, visual
signifier that any bolding I am doing should be done with respect to the
SWING_HTML.

The reason why that matters to me is because, as the number of my template
processors increases, I start to create little "groups" of template
processors that handle separate things. For example, I have processors in
regards to things like italicizing or bolding. Then I have ones in regards
to highlighting, which further delegates to color. But that is where the
warning bells went off -- how do I clearly differentiate between foreground
color and background color? Yes, obviously, I could just name them
foreground and background, but the point remains -- is the strategy to use
naming to differentiate it? Or is there some way to essentially compose
processors where I can dissuade, if not outright prevent, misuse of 2
similar but separate concepts? I really want to be able to lean into the
type system in order to get this, but I am not sure if that means I should
just forgo String Templates and jump straight into a method and do it the
"long way".

On Mon, Oct 23, 2023 at 10:42 AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Amber Dev Team,
>
> I have recently started playing with String Templates a lot more. They are
> an excellent feature that makes handling Strings safer and easier than
> before. I am pleasantly surprised.
>
> As the number of my String Templates grows (currently 6 on a single
> project), I am starting to think about how different String Template
> Processors work together.
>
> Currently, I am working on building a SWING_HTML String Template
> Processor, which wraps the text into <html> tags, replaces new lines with
> <br>, and does escaping. However, I also want to be able to do Swing HTML
> things, like bolding, italicizing, and more. More specifically, I want to
> elevate this functionality into the type system. My initial instinct is to
> delegate the task to other processors. For example, SWING_HTML."Hello
> \{BOLD."\{name}"}!"
>
> However, one thing that I want to be able to do is to be able to ensure
> that, if I do (for example) delegate bolding to another processor, then
> that certain processor is only ever used with my SWING_HTML processor. As
> in, a BOLD template processor does not make much sense if it is being used
> outside of my SWING_HTML template processor.
>
> I am not particularly attached to the delegating (don't want this to
> become an XY problem). But the primary goal of being a one stop shop for
> all things Swing HTML -- is that something I can do with String Templates,
> where the individual components like bolding and italicizing can be lifted
> into the Java syntax? Or is that asking too much/not worth the effort -- I
> should just stick to writing tags manually/interpreting certain character
> sequences as bold or italicized?
>
> In the same vein, I have another question.
>
> I am wondering if I am subtly drifting out of bounds of the goals of a
> String Template. The syntax is attractive, so I find myself using it often.
> However, I am starting to think that I am not using it for what it was
> meant for.
>
> For example, in my SWING_HTML processor, I find myself just passing in
> arguments like so.
>
> SWING_HTML."\{stringText}"
>
> It's technically valid, but is this the sort of thing that should just be
> a method instead? Is it more of a subtle border/gradient that we should
> decide as a matter of trade offs?
>
> Yet another question that builds off of the second one.
>
> Oftentimes, we receive a String that we would like to break apart into
> parts so that we can put it back together safely. Breaking it apart into
> parts is not the responsibility of String Template Processor, but putting
> it back together safely 100% is. Since String Templates are now (or very
> soon to be) the de facto way of putting Strings together safely/properly,
> what would be the the way of breaking them apart safely/properly?
>
> This question about parallelism in strategies is born out of seeing how
> you all are handling pattern-matching. Object construction and
> deconstruction are parallels of each other. It sort of leads me to wonder
> if there is a similar sort of play happening here for String
> deconstruction. My mind wants to say java.util.regex.Pattern/Matcher, but I
> want to confirm that.
>
> Thank you for your time and help!
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231023/d83f0988/attachment-0001.htm>