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). > 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. 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. > 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 > -- Thanks, Daniel Dekany
