this setting will change the following behavior in the language:
1.null can no longer be used as variable, the following throws a exception
2. the function structKeyExists return "true" in the following example:
"null" that is set in this case with the key "x" is a valid value.
it is also the much better behavior in general, then with the default behavior this function return false, even the function structKeyList is listening this key?! was a question last week in the mailing list btw
2. the function isDefined return "true" in the following example:
3. "empty" query (Resultset) cell do not return a empty string, the return null:
sound like a big problem for compatibility, but in CFML (Railo and ACF) "null" can be casted to a string without a problem, so the following
4. argument scope
the argument scope default behavior is strange, take this example:
in ACF ...
the first dump outputs null, the second dump throws a exception with the message "Element A is undefined in ARGUMENTS" and the third throws a exception with the message "Variable A is undefined"
in Railo ...
we have not followed the behavior from ACF, then the language should act the same way, independent of the syntax you access a variable, for us this is simply a bug in ACF.
to be as much as compatible to ACF we choose the following solution:
Railo return "null" in any case, so the same behavior for every call as ACF has for "writedump(arguments['a']);"
BUT when you enable "full null support"
it throws a exception like ACF does with "arguments.a", because null is a valid value we do not use as default value for arguments, but of couse you could still do
5. cfparam accept null as valid value
so the following does not throws a exception
i fact this is not working atm, but this is the expected behavior, so i have open a ticket for this