Le 21/01/2017 à 12:28, Daniel Dekany a écrit :
Saturday, January 21, 2017, 8:50:48 AM, Denis Bredelet wrote:
Hi Daniel,
FM2 traditionally uses a weird naming convention, where directive
names are all-lower-case (like #elseif), and other names use snake
case (like ?upper_case or date_format). For a while it also supports
camel case (you just use it in the template, like ?upperCase, #elseIf,
etc., and it switches to that mode automatically).
I belive camel case is the clear winner, because the names in the
data-model are almost always also use that, since in the Java world
that's the norm (also in the JavaScript world BTW).
I propose that FM3 should only support the camel case variation. (Note
that this only affect the names defined by FreeMarker, not the names
coming from the data-model.) That yet again simplifies tooling too.
Any thoughts?
-1 for supporting only camel case
I would just keep supporting all existing variations.
Note that this is for FM3, where the template syntax isn't compatible
with FM2 anyway.
Justification:
Camel case makes sense as you described, so it would be good to support that.
Directives like #elseif in the template will give an error if you
support only camel case. This is user hostile and I think we should
keep supporting the lower case variant.
If everything is camel case, then as one would expect, #elseIf is that
too. I think it's easy to grasp for the users (otherwise the error
message will tell them quickly). Note sure why it's user hostile. Or
if it's a bit that for some reason, if sparing that worths being
inconsistent with the naming convention of the data-model and of the
whole Java world really. (Maybe I'm more a purist that the average
users, but inconsistency like that irritates me.)
(BTW, in FM2, if you start using camel case in a template, it will not
accept #elseif either, only #elseIf.)
For built-ins, it is not entirely necessary to have snake case
variants.
Technically it's not necessary, but why it's not desirable? I mean,
you got `foo.someProperty` and `foo.someMethod()`, because that's how
they are in the data-model. You can't help that, that's given. And
then suddenly you have a `foo?some_stuff`. It looks inconsistent, and
as a user you have to switch back and forth your brain between camel
case more and snake case mode (and all-lower mode).
I don't like case inconsistencies in source code and I don't like snake case
for operators.
Using it for upper-cased CONSTANT is the only case (pun no intended) I can bear
with it
But if we have camel case then we should also support the all-lower case
variant,
All-lower is perhaps the worse accident in FM1-2 syntax. First of all,
it's the least legible one of the three. Secondly, there the template
language isn't even consistent with itself, as it's only used for
directive names.
as above. I believe that snake case helps legibility.
I don't think so. It's an old habit coming from old languages (COBOL, Fortran, you_name_it) and I don't find it legible at all. I farPreferCamelCase,
but that is a moo point I guess.
The most important is to remove the burden of having to deal with all the
variants.
Some "ecosystem" goes for snake case, some for all-lower case, and the
one we belong to (Java, even JavaScript on the Web designer side) is
pretty consistently uses camel case. I believe there's value in
consistency within the ecosystem you belong to. Also I think the more
syntax variations we support, the more confusing it is for the users
(think about the official documentation, or copy-pasting from
StackOverflow and other forums). Also having one variation simplifies
tooling and last not least FreeMarker itself. So, supporting 2 or even
3 variations has a quite high price, and I want to see what we gain in
exchange, too see if it worths it. So more concrete arguments are
welcome.
Examples:
support for ?jsString, ?jsstring and maybe also ?js_string
support for ?lastIndexOf, ?lastindexof and maybe also ?last_index_of
Configuration settings can be strictly camel case since they are
used by the programmers, not end users.
Because of #setting and some special variables they are also visible
to template authors. Also note that very often the template author is
a programmer too. Often even the same person.
Snake and all-lower cases: YAGNI I'd say. Once you use only one casing (CamelCase FTW) method, things are much simpler, for maintenance years later
for instance, but not only
Jacques
Cheers,
— Denis.
Also, for the configuration setting names we should only support camel
case too (FM2 supports both). Those are used outside templates too,
like when you load the configuration from *.properties.
Of course, if someone uses a snake case name, we would tell in the
error messages that names are camel case since 3.0.0.
--
Thanks,
Daniel Dekany
