CFML: "Elvis" operator and null coalescing operators are two different things

Description

See http://blog.adamcameron.me/2015/07/cfml-elvis-operator-and-null-coalescing.html, and as discussed in LDEV-467.

Bottom line:

Now the CFML version:

Result:

Which is... wrong.

Activity

Show:
Former user
August 17, 2015, 7:52 AM

At present the CFML implenetation needs to remain as-is, null-coalescing, for compatibity with ACF.

Going forwards I believe the Lucee implementation should have actual elvis and null-coalescing operators in line with other languages.

Additionally if ACF corrects their elvis then we should do also.

Michael Offner
August 17, 2015, 8:36 AM

in my opinion this would be a bad move then this

would no longer work, "false" is a valid value, like "null" is as well when full null support is enabled.

Adam Cameron
August 17, 2015, 8:52 AM

Even with "full null support", null is not a falsey value in CFML is it?

The Elvis operator is not supposed to be a null check, it's simply supposed to be a short-hand version of the ternary ?: operator, for which the first operand is a boolean.

The null coalescing operator - which is a different thing - evaluates for null rather than boolean. But that's not ?:.

In some languages null is falsy, but CFML is not one of those, so there are two distinct operators here: "binary ?:" and "null coalescing" (often ??). There is no overlap between the two.

The issue here is that Railo or Lucee (and, for that matter: ColdFusion) incorrectly implemented ?: as a null coalescing operator. This is not right.

The call here is whether Lucee should continue to mirror CF's incorrect behaviour. I think the answer to that is - unfortunately - "yes". It would cause more problems than benefits if it behaved differently, given people already seem to have a fairly tenuous grasp on what this thing is supposed to do. I'd just document it accordingly.

Former user
November 7, 2015, 3:38 AM
Edited

I agree with your assertion that acf and railo/lucee got the implementation wrong on this but I don't agree with your conclusion to maintain compatibility. I say this for a couple of reasons.

  1. First and most importantly Lucee actually has proper null support while acf does not. RIght out the gate the two are different so lucee needs to have proper null coalescing support.

  2. While it is obviously not desirable to require code changes when migrating between engines, it is far from hard to scan for "?:" in a codebase when migrating and fix where necessary.

  3. Bringing in developers from other languages is never going to get better while cfml consistently goes against established language conventions.

  4. While I don't think it will ever be admitted in public, I strongly suspect that the cf team in adobe are starting to take their language design queue's from what lucee is doing (eg pass by reference arrays in cf12). This is a perfect opportunity for lucee to correct a mistake which I believe was actually made by railo/lucee while this feature is still lightly used.

Assignee

Unassigned

Reporter

Adam Cameron

Labels

None

Affects versions

Priority

Minor