tracker issue : CF-3710381

select a category, or use search below
(searches all categories and all time range)
Title:

Null coalescing operator not quite implemented correctly

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/AsDesigned

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 02/19/2014

Components: Language

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: PublicBeta /

Priority/Frequency: Major / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 1

See http://cfmlblog.adamcameron.me/2014/02/coldfusion-11-good-stuff.html#nullCoalescingOperator

Extract:
The null-coalescing operator is a binary operator that works thus:

result = firstValue ?: secondValue

The rule being that the result will be the firstValue if it is not null, otherwise it will be the second value. Simple. Both Railo and now ColdFusion have messed it up a bit though, confusing the concepts of "null" with "not defined".

This demonstrates the correct operation of the null-coalescing operator:

//nullCoalescingOperatorCorrect.cfm
nullVariable = javaCast("null", "");
variableToSet = nullVariable ?: "default value";

writeDump({variableToSet=variableToSet});

This outputs:

struct
VARIABLETOSET	default value

because nullVariable is null, it's not used for the value of variableToSet; "default value" is instead.

However this demonstrates where CFML goes a bit wrong:

// nullCoalescing.cfm
variableToSet = notDefined.invalidProperty ?: "default value";

writeDump({variableToSet=variableToSet});

This should error. Because notDefined isn't null, it's not defined. And something that isn't defined cannot have a property (. operator), so notDefined.invalidProperty is just an error situation. However this "works" in CFML:

struct
VARIABLETOSET	default value

I raised this yesterday with Railo: "Probable bug in null-coalescing operator", and Igal and I just got the hump with each other, but Gert is erring towards "right or wrong, I'd prefer 'wrong'". I'd prefer "right". The way to solve it so that everyone is happy would be to additionally implement the safe navigation operator, as I mention in an earlier article: "Thinking about operators in CFML". This way we have the ?. operator acting how it's supposed to, and the ?: acting how it's supposed to. Not implementing ?: so that it alters how the . operator works.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3710381

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

"as designed"? You guys don't get to *design* how standard operators work. The behaviour of the null-coalescing operator is well defined in other languages, and you've ballsed it up in CF. -- Adam
Comment by External U.
13437 | April 10, 2014 04:48:49 PM GMT
+1 - The design is flawed and conflicts w/ other languages. Undefined <> NULL.
Vote by External U.
13439 | July 30, 2015 01:38:55 PM GMT
Belay this. There's been confusion (on my part, and others, and clearly Adobe's too) as how how the ?: is supposed to work. It still doesn't work properly, but it's more wrong than I indicate here. There is another ticket covering this: https://bugbase.adobe.com/index.cfm?event=bug&id=CF-4028653 Also read this: http://blog.adamcameron.me/2015/07/cfml-elvis-operator-and-null-coalescing.html
Comment by External U.
13438 | July 31, 2015 12:38:49 AM GMT