So this is some easy to understand stuff, compared to the totally
unpopular "[FM3] Call syntax, positional and named parameters" thread
at least (and silence is approval, for the sake of progress).
Note that all of these changes can be done automatically with the
FM2-to-FM3 converter (which is work in progress).
Note that anything between ` characters is code quotation, and the
` character itself is not part of the proposed syntax.
So, the proposed changes:
- Switch to camel case everywhere. This was already discussed months
ago, I'm just saying it again. Other than that convention has become
overwhelmingly popular in the Web and Java world, one reasons is
that the Java API-s you call from the template uses that convention
anyway. Also, remove the namingConvention setting. If someone needs
a different convention (snake_case, typically), they should use the
planned custom dialect feature. It's cleaner and more powerful that
way, for example, you could even use non-English names.
- Remove the long deprecated #{}.
- Remove `=` as an alias to `==`. This removes ambiguities caused by
that passing parameters by name and assignment also uses `=` with a
different meaning.
- Remove `&` and `|`, as they are just aliases to `&&` and `||`. This
will also free up these symbols for future usages.
- Add `and` and `or` as keywords. `and` is useful when you can't use
`&&` because it's not well formed XML/HTML (which matters as some
real-world applications impose such strange restrictions on
templates... it's totally weird, but that's how it is). `or` is only
for the sake of consistency. FM2 `\and`, `&&` would be
removed (which is kind of funny, as they are added in 2.3.27, which
is still under development).
- Regarding the aliases of the `<`, `<=`, `>`, `>=` operators:
- Replace `gte` and `lte` with `ge` and `le`, to be more similar to
XSLT and XPath.
- Remove `\gt`, `\lt`, `\gte`, `\lte`. They are deprecated for a long
time.
- Remove support for `>`, `<`, `>=`, `<=`. Some may
point out that these were practical when you enter tags into WYSIWYG
editors (i.e., your tags get mangled by unwanted escaping).
Problem is, it has never worked 100% correctly for those
applications, as other characters may be escaped there as well,
such as an `&` in a string literal, or even quotation marks. So to
support that use case, we will need to add a feature that properly
un-escapes everything (even tag delimiters!), instead of adding
hacks to the expression syntax that only work around the problem
sometimes.
- Fix `exp!exp` precedence. In FM2 `a + b!c + d` means `a + b!(c + d)`,
which is just wrong. It should mean `a + (b!c) + d`, but it can't be
fixed there as it's not a backward compatible change.
- Less liberal comment syntax inside expression.
In FM2, inside expressions (as opposed to between tags), you can use
all of these as comments, regardless of the tag syntax: `<#-- -->`,
`[#-- --]`, and surprisingly even `<!-- -->`. In FM3, you could only
use either `<#-- -->` or `[#-- --]`, whichever matches the tag
syntax of the template.
- Interpolations shouldn't be string-escaped anymore in string
literals. In FM2, when you have an interpolation inside a string
literal, its content has to be properly backslash escaped, just like normal
characters in the string, for example:
`${"A backslash: \\. Another backslash: ${'\\\\'}"}`
or `${"Foo ${\"Bar\"}"}`
This is not very user friendly IMO, and also complicates parsing
considerably (bad for us, bad for 3rd party tooling). I have checked,
and nor Groovy nor Kotlin does this. So in FM3 you had to write
this:
`${"A backslash: \\. Another backslash: ${'\\'}"}`
or `${"Foo ${"Bar"}"}`
- SQL-like quotation character escaping in raw strings literal. Raw string
literals are like r"\d+" or r'\d+'; both literally means \d+. You
can include any characters without escaping, in fact there's no
escaping inside raw string literals. Problem is, then you can't
include the literal quotation character in the content, as there's
no way escaping it. I propose we allow that like this:
r'It''s an example.' or r"This is ""quoted""."
--
Thanks,
Daniel Dekany
