Does this mean that some move to remove currently incompatible CFML will be undertaken (and perhaps re-homed in “lucee lang”), or is it more a “line in the sand” and this means “from now on”?
Ideally with two language flavours now, Lucee’s CFML implementation would be modified to not have any purposeful incompats with ColdFusion’s “reference” CFML. Perhaps by moving purposely incompatible code out into a separate module (which can be installed for Railo compatibility).
However that “ideally” itself might not be actually “ideal” if the context is only the former-Railo-now-Lucee community codebase, which might leverage incompats.
Maybe Lucee 5’s CFML implementation can break backwards compat, moving it back closer to ColdFusion’s? TBH I see almost all of Lucee’s CFML “enhancements” as barriers to cross compatibility, rather than really being that beneficial. I understand the motivations behind them, but now think perhaps it’s the job of .lucee to have stewardship of that sort of thing.
Regarding breaking the Lucee backwards compatibility to Railo in favour of compatibility to ACF, I can see where you are coming from but I think doing this now would just confuse matters. Perhaps it should be more of an aim going forwards to ensure any new implentations / work on CFML are ACF-compatible with a view to bringing any pre-existing incompatibilities back into line without breaking Railo compatibility where possible.
The main problem I see with trying to apply this retrospectively is simply who is going to actually be there making the code changes? It’s fine talking about it but I don’t see there being enough developer resource to retrospectively make everything within Lucee entirely 100% ACF compatible, especially without breaking Railo compatibility.
In summary, that statement from the manifesto I would interprete to mean that this is a line in the sand going forwards, and something to aim for when working on older code with respect to bug fixes / reconciling breaking incompatibilities. I know that with respect to bugs like LDEV-90 I use ACF as reference for how it should behave.
Firstly - as with a lot of stuff I mention here - I’m thinking of the theoretical side of things, not the implementation thereof. And I’m not intrinsically indicating my own position on things, more just thinking the discussion might possibly need to take place.
One thing I will say though, is I think a shortage of dev resource shouldn’t necessarily be much of a consideration when deciding whether something ought to be done. If it’s decided that the Lucee CFML implementation ought to mirror ColdFusion’s then the work needs to be done. It will go into the bucket of “things that need to get done” along with stuff like “implement ” and the likes. Then priorities are drawn from that, triage takes place, and work is planned, scheduled and undertaken accordingly. It might mean needs to take a back seat whilst Lucee gets the rest of its CFML house in order
And I think Lucee - Association, project, platform, language, etc - is still in the process of getting its ducks in a row, so if the manifesto says “Lucee’s CFML implementation strives to be ColdFusion compatible”, the decision to make then is… [as per my initial post on this thread].
If it was important, and given Lucee 5 is a full version release (so backwards compat can be sidelined for the greater good of the language/project), and it’s currently in development… now is precisely the time to be thinking about this. Not later.
But - bottom line - I am very much just asking a question, not making a statement here.
That is the Members interpretation. It’s with reference to the availability of Lucee Language. So until we have a Lucee Language available to push differences into we’re stuck where we are.
People who have apps written to work on Lucee 4.5 (and indeed Railo) should expect their apps to continue to work without alteration. I think we need to endure the overhead of making existing CFML, and Railo/Lucee flavoured CFML syntaxes work side by side, while improving CFML compatibility where we can.
What is more controversial is whether or not something like Static features should be part of Lucee 5’s CFML dialect. This is another clear break with existing CFML, and if Adobe introduce “Static features” at some point in the future you can all but guarantee it will have a different syntax.
Should “Static features” be part of Lucee 5 CFML? It’s a hard one because the feature is already written. I am inclined to think we should remove Static’s from Lucee CFML and wait till Lucee Language is good to go; only introducing Static features to the CFML dialect if and when Adobe do, and in their syntax. That is not a universal view amongst Members, and might be a topic for the TAG to consider.
If Lucee Language is going to cause a significant delay to the release of Lucee 5, there is every possibility that Lucee 5 will not ship with Lucee Language except in an “experimental” state. In the scenario outlined above, we’d be shelving Static features for a while.
Hence my suggestion “Perhaps by moving purposely incompatible code out into a separate module (which can be installed for Railo compatibility).”
This way one would have Railo compat and ColdFusion compat at the same time, plus following the “reference” implementation of CFML (ie: Adobe’s). There’s 100% overlap on those last two, but they’re commenting on different aspects of the same thing
Also full-version releases of newly launched products (and let’s see Lucee this way) should not really have a problem with breaking backwards compat. However I still maintain one should not do this, but to move the Railo-specific features out into the Railo compat module, as mentioned initially.
I don’t think it’s controversial at all: indeed it’s almost a no-brainer: move that stuff out of CFML and into .lucee. If your position is to strive towards CFML compat, and have a different solution for experimenting with non-CFML features, then Lucee 5 (beta, remember) is percisely the time to stop putting off-piste CFML features into the CFML engine, and add it to .lucee. It has the dual benefit of making it seem like you’re taking this “Compatibility with ColdFusion” thing seriously, but it gives a value-add to .lucee (which is pretty short of value-add right now).
What an excellent idea. I wish I had thought to suggest that. Oh, hang on…
I don’t think it’s controversial at all: indeed it’s almost a
no-brainer: move that stuff out of CFML and into .lucee. If your
position is to strive towards CFML compat, and have a different solution
for experimenting with non-CFML features, then Lucee 5 (beta, remember)
is percisely the time to stop putting off-piste CFML features into the
CFML engine, and add it to .lucee. It has the dual benefit of making it
seem like you’re taking this “Compatibility with ColdFusion” thing
seriously, but it gives a value-add to .lucee
.lucee doesn’t need to be compatible at all IMHO, it isn’t CFML, it’s Lucee?
If you want to make it compatible with other CF engines write in CFML/CFScript simple.
I am looking for CF alternative and I am glad to find Lucee and mostly compatible and it would be very unfortunate if Lucee chooses the path to be incompatible with CF.
I think it is good to have more advanced features and be incompatible but I think it should be an add-on for those that want them.
Hi chanhong. Thanks for the comment. Yes, the #1 design goal for Lucee is CFML compatibility, and that will always be the case. The next highest priority for how we develop Lucee is what you suggested–advanced features that help developers do their jobs better and faster. (Actually, that might be tied for 1st place in terms of importance!) And we’d also agree with you that from Lucee 5 onward add-ons (extensions) will be a really important option for implementing advanced features.
