freemarker-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Dekany (JIRA)" <>
Subject [jira] [Commented] (FREEMARKER-77) expr!! as a shorthand for (expr)!
Date Mon, 02 Oct 2017 09:54:00 GMT


Daniel Dekany commented on FREEMARKER-77:

I'm hesitant to add any more odd looking operators... unless I'm sure that they will be part
of a nice consistent system, as opposed to one more syntactic sugar. Anyway, first I want
to see FM3's null handling to be implemented, because what I really want to avoid is having
{{!!}} there with a different meaning. As things stand, in FM3, when it's ever implemented,
you write things like {{foo!.bar.baaz}}, {{foo!.bar!.baaz!}}, etc., that is, you only put
{{!}} after things that can be {{null}}, and not after the things that can only be null because
of another {{!}}. And then, we don't even have {{(exp)!}}, because that's was a silly idea
on the first place. I mean, removing that {{(}} and {{)}} shouldn't mater in the last, right?
It's should be just like {{x + y}} is the same as {{((\(x))) + ((\(y)))}}. So these might
can change what's badly needed. And there's a chance that in FM3 {{!!}} will be used for taming
{{undefined}} as opposed to taming {{null}}-s, which is differentiation that doesn't exist
in FM2. After FM3 null handling is settled, I we can be more brave in adding convenience features
in FM2.

> expr!! as a shorthand for (expr)!
> ---------------------------------
>                 Key: FREEMARKER-77
>                 URL:
>             Project: Apache Freemarker
>          Issue Type: New Feature
>            Reporter: Ondra Žižka
>            Priority: Minor
> a.very.long.expr!! could be a shorthand for {{(a.very.long.expr)!}}.
> The effect of !! would go back to the "root" of the expression, i.e. at the start of
the part ending with !! . Not sure if that would have clear enough rules, though.
> The use case is, that often there is a long expression, (again, getting something from
a deep graph), and anywhere on the path something can be missing. The only relevant thing
is at the end. And the parentheses make the expression less readable.
> Example made-up situatuon:
> {code}
> ([(foo.transform((a.very.long.expression())!"defaultResult"))!fallbackKey(context)])!"-"
> {code}
> 1) The long expression can be missing at any point, so the transform would get some default
> 2) The transform may return null if the argument is somehow improper. For that case,
the {{fallbackKey()}} would return a key as per the {{context}}.
> 3) If the map doesn't contain the entry or any of {{}} is missing, the whole
expression would turn into {{"-"}}.
> {code}
> {code}
> Ok, this one is perhaps a candidate for splitting into few steps. But it's just for illustration.
> Does it make sense? Is it doable?
> Marking it as minor as it's not really too much pain, just would be nice to have.

This message was sent by Atlassian JIRA

View raw message