Copied from https://issues.jboss.org/browse/RAILO-1510
Bruce said:
I was surprised that "optional semicolons" became a feature. Please forgive me if this has been considered already, but perhaps the railo team could consider a strict Adobe Coldfusion syntax behavior mode as a global setting so that it would be possible to develop in Railo and still deploy to Adobe Coldfusion later. For example, if I wanted to distribute my framework and let others decide which CFML server they wish to run. I'll need to test anyway, but at least having consistent syntax would save a lot of time. It is too easy to forget semicolons especially when you are going between javascript, php and coldfusion in the same day. I run my own company and while I may choose to deploy Railo on my production server soon, I also work for another firm who may prefer to continue running Adobe's version. It helps if my code continues to be easy to run on Adobe's version. It requires a great deal of ram to run both railo and coldfusion with sessions and shared memory cache all fully loaded at the same time so I'd like to avoid this as much as possible. Thank you for the excellent work so far.
had added a comment:
I don't know how much work adding this option would be so I'll leave the decision up to Micha but I wanted to point out that Adobe ColdFusion Builder does a great job of highlighting syntax that won't work on Adobe ColdFusion. I use CFBuilder for all my Railo development and it really helps me keep my code portable (in terms of syntax - Railo supports a lot more tags in cfscript, optional semicolons and the ability to dynamically call methods in cfscript: obj[method](args) - which is a syntax error on ACF; CFBuilder highlights all of those).
I'm a bit surprised Adobe still hasn't allowed semicolons to be optional. They're optional in ActionScript and JavaScript so it would be more consistent for them to be optional in cfscript as well.
Looking at this in preparation for TAG meeting 16/09/15.
Given the idea of moving Lucee into a situation with an ACF-compatible CFML language as well as LuceeLang for new features that can part with ACF-compatibility, wouldn't this be best solved by going forward making it required (as ACF does) in LuceeCFML and make them optional in LuceeLang?
TAG recommends admin configuration. Classic vs modern for example. Setting also available via Application.cfc.
Fixing status based on new workflow. Rejecting just to get it to "start over".
Vote taken
[ 5 votes ] Reject
[ 3 votes ] Add to backlog
1 abstentions
Reasons for rejection
Portability checking is the remit of a separate tool such as ColdFusion Builder
Unless Lucee decides to add a full strict ACF compatibility mode there is not much point in addressing the issues piecemeal
If Adobe wish to support all CFML that Lucee does they are welcome to do so, it is up to Lucee to ensure code that works on ACF also works on Lucee and not the other way around.