Full support for "null" in Railo

[Michael Offner]

Should Railo have full support for null as a option?

Let me do a example to explain what this means.

test=null; // set null to key test

echo(test); // output null

ATM using null in CFML is a mess, because it is only halfway supported, for example CFML makes no difference between null and not existing.

but you can pass null and sometime you get null

What do you think?

Micha

Michael Offner CTO Railo Technologies GmbH

[Geoff Parkhurst]

On 19 November 2012 11:15, Michael Offner <mic...@getrailo.com> wrote:
> Should Railo have full support for null as a option?

+1

(At the very least it would make my code *look* a lot better - no more
0 for ids, empty strings when I really mean not defined at all etc)

[James Kilford]

A resounding yes from me.  It would be useful to tell the difference between null and empty string.  

On 19 November 2012 11:15, Michael Offner <mic...@getrailo.com> wrote:

[Hendrik Kramer]

+1 from me too. However, two questions:

a) does this impact the overall performance more than expected?
b) is this also supported for serializeJSON()?

[Michael Offner]

a) whatever we do, it will not impact performance, atm i'm not sure how to make this configurable.

b) already supported today, so no change for serializeJson 

Micha

2012/11/19 Hendrik Kramer <hendrik...@gmail.com>

+1 from me too. However, two questions:

a) does this impact the overall performance more than expected?
b) is this also supported for serializeJSON()?

--

/micha

[Jeroen Knoef]

Most definitely!
Would the behaviour of structkeyexists then change? I.e. if a key exists and is null, this returns false now. What happens if a key doesn't exist? Eg. would this work: struct.a == null, if there is no key a (also not a null valued one)?

(I hope both questions have a yes)

[Jared Rypka-Hauer]

Only if it doesn't change current behavior at all... i.e. "null" in this case needs to mean "equal to all the ways people currently detect a potentially null value AND support for real nulls".

If it's going to start returning NULL where it used to return "" or 0 or even stop throwing errors where people have try/catches in place to deal with null values (something people have to resort to from time to time), then it's going to break too much code and I can't imagine that this kind of syntactic sugar would be worth the pain it would cause.

Or, at the very least, be configurable in 3 modes:

NULL mode, where it replaces current behavior
MIXED mode, where it continues to support the way people already do things AND supports functions and tags that regognize NULL as itselt plus synonymous with "" and 0 and so on.
LEGACY where it supports the way things currently work with no changes whatsoever.

That's about the only safe way I can see to make this useful without breaking a million billion lines of code. :)

J

[James Kilford]

Yes, it would be good if it were another parameter switchable via the administrator...  New projects could then benefit from extra Railo goodness.  

On another note, would null support extend to picking up nulls from database queries?

[Michael Offner]

see my answers in text, but the answer to all your questions is very easy.

null is like every other value as well, so you can ask yourself what is happening if the value for example is "susi".

Micha

2012/11/20 Jeroen Knoef <jer...@neoneo.nl>

Most definitely!
Would the behaviour of structkeyexists then change?

Yes

 

I.e. if a key exists and is null, this returns false now.

because null is a valid value like every other, it will return true in this case

 

What happens if a key doesn't exist?

still return false

 

Eg. would this work: struct.a == null, if there is no key a (also not a null valued one)?

if struct.a exists and is null it returns true, if struct.a does not exists it throws a error

 

(I hope both questions have a yes)

[Michael Offner]

of course this feature will be configurable and by default we will have the old behavior.

Micha

2012/11/21 Jared Rypka-Hauer <armcha...@gmail.com>

--

/micha

[Michael Offner]

if null is supported, we no longer have to convert null values to something else, i'm not in favor of a mixed mode. i think something like this is confusing for most users.

Micha

2012/11/21 James Kilford <nkil...@gmail.com>

--

/micha

[Stefan]

Yes please! I used to think null was a stupid idea, a hack, that someone invented long ago by a Monday morning after a bad weekend. I do not think so no more. It is a lot easier to write sane code with null and I think that if Railo in the future will proceed towards being "typed", null is no longer an option.

[Martijn van der Woud]

Yes please! The current implementation is a nightmare.

var myvalue = someFunctionCallThatReturnsNull();

IsDefined('myvalue')
May return true because myvalue no longer exists in the local scope so ColdFusion now searches through variables, URL, form, cookie scopes. Dangerous stuff.

[Rainer Schreiber]

+1 please!

No more null placeholders, no more empty strings as null, no more 0 values for integers, and finally the possibility to reckognize a boolean that has not been set!

And I would go a step further; f**k the cfml advisory commitee, and make nulls default available in Railo :p

Cheers Rainer.

[Michael Offner]

FYI

Now Railo 4.1 supports null

https://issues.jboss.org/browse/RAILO-2194

mean code like the following is now working:

<cfset y=null><!--- null is a literal now --->
<cf_valueEquals left="#isNull(variables.y)#" right="#true#">
<cf_valueEquals left="#variables.y == null#" right="#true#">
<cf_valueEquals left="#variables['y'] == null#" right="#true#">
<cf_valueEquals left="#y == null#" right="#true#">
<cf_valueEquals left="#isDefined('variables.y')#" right="#true#">
<cf_valueEquals left="#structKeyExists(variables,'y')#" right="#true#">

What does this change?

variables with name null are no longer supported, because this is a resered word now.

structkeyExists, isDefined, arrayIndexExists or arrayIsDefined now return true if a key/index exists with the value null.

variables containing null can now be used and no longer throw a error.

So this change of course can affect existing code, atm this setting is not configurable (Railo 4.1 Alpha), because it is extremely complicated to make this configurable without have a negative impact on performance. the decision if this will be configurable and what behavior will be default, will depend on your feedback.

Micha

2012/11/22 Rainer Schreiber <rai...@evalentis.nl>

--

/micha

[Chris Blackwell]

Good work! 

[Rainer Schreiber]

This is just A*W*E*S*O*M*E !!!

You guys really rock!

Thanks a lot,

Cheers Rainer.

[Rainer Schreiber]

And BTW: please, make the NULL's default :P

On Wednesday, December 5, 2012 2:17:02 PM UTC+1, Michael Offner wrote:

[Seb Duggan]

This looks good to me. Can't see any advantage in making it configurable - it's a very quick check to see if your code is using "null" as a variable...

- Seb

On 5 December 2012 13:17, Michael Offner <mic...@getrailo.com> wrote:

[Brad Wood]

What will happen when outputting nulls from a database query? What will get output with <cfoutput> #myNullVar# </cfoutput>?
Also, how will operators treat null like concatenation or addition? Ie, what is a string concatenated with null our a number added to null?

I can't recall any coalesce() kind of functions. Would one make sense now?

Any feel for a final release date out of curiosity? I think we'll need some changes in ColdBox to support this change.

Thanks!

Brad

[Brad Wood]

That's a good reason to do local.myValue = nullFunc();

IsDefined("local.myValue") is a bit more specific as long as you haven't defined variables.local.myValue :)

Brad

[Brad Wood]

I don't think using "null" as a variable name will be what trips most people up. (ironically, if your "null" variable actually contains a null value you probably could just leave out be.)

The pain points will come for people who treat null struct keys as non-existant, etc. Especially frameworks that need to maintain compatibility with ACF and previous versions of Railo. What's worse is the code might not error, but just quietly start producing different results.

Brad

[Pionic]

Good stuff ! Will the null values also be returnable ? At the moment we use constructions like return isNull(x) ? nullValue() : x; but preferably we would just like to use return x;

[Michael Offner]

See my answers in text, please have in mind that the current implementation is just a alpha release, everything is still open for debate.

Micha

2012/12/5 Brad Wood <br...@bradwood.com>

What will happen when outputting nulls from a database query?

there is no change with that, null in query object is still equal to a empty String, a lot of code is depending on this behavior, but we could make a configuration setting for this.

 What will get output with <cfoutput> #myNullVar# </cfoutput>?

this is something that has not changed, like you know null was already halfway supported, we plan not to change existing behavior if it comes to null, take the following code, that is already working in Railo (any version) and ACF.

<cffunction name="nulls"><!--- return null ---></cffunction>

<cfoutput> #nulls()# </cfoutput>

if you output null, null is converted to a empty string, 

 

Also, how will operators treat null like concatenation or addition?  Ie, what is a string concatenated with null our a number added to null?

same as above, because already in past null could be a oprant, there is no change here 

I can't recall any coalesce() kind of functions.  Would one make sense now?

Any feel for a final release date out of curiosity?  I think we'll need some changes in ColdBox to support this change.

this will be in Railo 4.1, first beta is planned for end of this year! 

Thanks!

Brad

[Michael Offner]

isNull perhaps will be a better choice in many situations now

Micha

2012/12/5 Brad Wood <br...@bradwood.com>

That's a good reason to do local.myValue = nullFunc();

IsDefined("local.myValue") is a bit more specific as long as you haven't defined variables.local.myValue :)

Brad

--

/micha

[Michael Offner]

you will be able to handle null the same way, you handle every other object,

the only question is, how is null converted to other types (see questions before)?

Micha

2012/12/5 Pionic <pion...@gmail.com>

Good stuff ! Will the null values also be returnable ? At the moment we use constructions like return isNull(x) ? nullValue() : x; but preferably we would just like to use return x;

--

/micha

[James Kilford]

Blimey, that was a quick turnaround!

> What will happen when outputting nulls from a database query?

>> there is no change with that, null in query object is still equal to a empty String, 

>> a lot of code is depending on this behavior, but we could make a configuration setting for this.

I think this would be a very useful feature -- to determine if a database record has null values or has been read with empty string.  The best solution for me would be: if you want to use the null value, it's just an empty string, but if you want to check the value, then Railo can tell you it was really a null.  

James

[Michael Offner]

perhaps we could return null, Railo can convert null to a empty string anyway.

Micha

2012/12/5 James Kilford <nkil...@gmail.com>

[James Kilford]

That would be great!

James

[Michael Offner]

but i think we have to give all this changes a try and see how much this affects existing code.

[John Willis]

2012/12/5 Brad Wood <br...@bradwood.com>

What will happen when outputting nulls from a database query?

there is no change with that, null in query object is still equal to a empty String, a lot of code is depending on this behavior, but we could make a configuration setting for this.

It would be handy to be able to test for nulls in the database. Even a dedicated function would be handy. 

[Peter Boughton]

> It would be handy to be able to test for nulls in the database.

SELECT stuff FROM table WHERE column IS NULL ?

[Peter Boughton]

Also, most DBs have an ifnull(col,value) or isnull(col,value) function, useful to default nulls to a particular value.

[Igal]

you mean, like the Elvis operator?  ;)

[Hendrik Kramer]

The only problem I can see is the <cfargument> tag with non-required field without setting a default.

E.g.

<cfargument name="someArg" required="false" /> will be returned as "NULL" when you dump(arguments); and we use this with if( structKeyExists( arguments, 'someArg') ) { ... }

I assume we need to rewrite this? The use case is to add filter criterias to SQL queries for city, postalcode etc. all optional. We could use "" as a workaround or isNull() maybe?

[Michael Offner]

Fair point.

cfargument and null handling is really a mess and railo already break compatibility to ACF here a little bit.

ACF makes a difference between dot notation and bracket notation here?!

so if a argument was not defined with a call, ACF set x to null in the following example 

<cfset x=arguments['arg1']>

but throws a exception with the following code

<cfset x=arguments.arg1>

Railo makes no difference between dot and bracket notation.

But the question is, how to handle all of this with full null support?

the question is, should we have a difference between the following 2 calls of the function "test".

function test(a){

   dump(a);

}

test();
test(null);

should with the first call "a" be null or not existing?

in Railo < 4.1 and ACF structKeyExists is working illogical anyway, take the following example (working with any Railo version)

variables.x=nullValue();

dump(structKeyExists(variables,'x'));

in that case older Railo versions return false, but the key is existing, you can for example do the following

dump(listFindNoCase(structKeyList(variables),'x'));

and this is returning true.

Yes you can use isNull in this case.

in the end the answer is very simple, if a argument is not passed, it should not exist, so your code will work as before.

Micha

2012/12/6 Hendrik Kramer <hendrik...@gmail.com>

[Hendrik Kramer]

> in the end the answer is very simple, if a argument is not passed, it should not exist, so your code will work as before.

Perfect! We don't need the argument to be null, if we could rely on the fact that structKeyExists returns false for non-passed, non-required arguments without a default, that would be perfect.

At all, +1 for full null support of course.

[Bruce Kirkpatrick]

null = empty string to me.   I'd never want to check database fields for null vs empty string - Don't other languages force that on you like classic ASP?.   I've never seen null used in CFML and it would only make for writing more validation code if it didn't equate to empty string.   CFML needs to continue to be a "write less" language when it adds features.   I don't want it to become too complex and inconsistent like C++ or PHP.  I wouldn't mind if CFML was more like Java though.

[Michael Offner]

Cfml is based on java and java use null, ATM null comes to surface sometimes anyway, for example this way
Variables.Test=udfcall();
If the udf called does no "return", the variables scope now contains a key test with value null.
What is structkeyexists(variables,"test") now returning, there is a key "test" but the value is null, what is isdefined returning? Are you a 100% sure about the answer without checking?
Make the answers to this questions sense?
Null already exist in cfml, the problem is that null handling is not consistent and Railo 4.1 only try to make this accurate.
Railo is able to convert null to a empty string, so you don't have to change to much, take this code
Test=null&query.nullvaluecolumn;
Result is a empty string

Micha

Von meinem iPad gesendet

[Ronan Lucio]

It's just awesome.

I don't like to declare variables if a wrong type:

var q_Products = ""; // it will be a query, not a string

I have two doubts:

1) What will return Len(nullVariable)?

2) What will return isEmpty(nullVariable)?

Ronan

[Michael Offner]

see my answers in text

Micha

2012/12/20 Ronan Lucio <ronan...@gmail.com>

It's just awesome.

I don't like to declare variables if a wrong type:

var q_Products = ""; // it will be a query, not a string

we also working on the possibility to just declare variables, so this

var q_Products;

will be the same as

var q_Products = null;

 

I have two doubts:

1) What will return Len(nullVariable)?

there is no change with that, like today in ACF and Railo this returns "0"

take this code as example

function nulls(){}// returning null in Railo and ACF

writedump(len(nulls()));// outputs 0 in Railo and ACF

2) What will return isEmpty(nullVariable)?

there is no isEmpty function in Railo or ACF, but please have in mind that Railo and ACF can handle null values already, there are just some gaps to fill

 

Ronan

[Ronan Lucio]

Michael,

Awesome!!

About isEmpty():

I'm talking about that http://blog.getrailo.com/post.cfm/isempty-function

I thought it would be included on default version 4.

Ronan

2012/12/20 Michael Offner <mic...@getrailo.com>

[Michael Offner]

This UDF will return 0, as it already does today, btw railo has a function called "empty" that exists longer than this blog entry, perhaps gert was not aware of this ;-)

[Ronan Lucio]

OK,

Thank you

2012/12/20 Michael Offner <mic...@getrailo.com>

[Gert Franz]

No he wasn't... He must first find out what empty() does :-)

--
Gert Franz
Sent from somewhere with my iPhone

[Matt Quackenbush]

Takes out the trash?

[Igal Sapir]

Too simple...  In the spirit of CFML the function for that would be:  TrashTakeOutAndEmpty()

--
typos, misspels, and other weird words brought to you courtesy of my mobile device.

[Igal Sapir]

For the sake of consistency -- shouldn't the Empty() BIF be named isEmpty() like the other decision functions?

If so -- we should do it now before Empty() gains popularity and much use

Igal

--
typos, misspels, and other weird words brought to you courtesy of my mobile device.

[Matt Quackenbush]

+1

[Gert Franz]

+1.5

Von meinem iPad gesendet

[Adam Cameron]

Agreed. empty() implies the function does some sort of emptying operation, not testing whether something is empty.

--
Adam