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. 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. For built-ins, it is not entirely necessary to have snake case variants. But if we have camel case then we should also support the all-lower case variant, as above. I believe that snake case helps legibility. 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. 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
