[
https://issues.apache.org/jira/browse/FREEMARKER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187825#comment-16187825
]
Daniel Dekany edited comment on FREEMARKER-77 at 10/2/17 9:55 AM:
------------------------------------------------------------------
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.
was (Author: ddekany):
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: https://issues.apache.org/jira/browse/FREEMARKER-77
> 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.bar.baz[(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 value.
> 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 {{foo.bar.baz}} is missing,
> the whole expression would turn into {{"-"}}.
> {code}
> foo.bar.baz[foo.transform(a.very.long.expression()!!"defaultResult")!!fallbackKey(context)]!!"-"
> {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
(v6.4.14#64029)
