Wednesday, September 9, 2009

Should CF9 officially introduce the null value?

Thank you Adobe for giving us IsNull() function, and we can finally use that instead of the more verbose StructKeyExists() or the less efficient IsDefined(), but how do I set a variable to null?

When do we need to set a property to null?  How about a property in a persistent=true component that represents a nullable column? 

Let’s say for the Member table, the gender field is optional, the gender column is nullable.

option 1: setGenderNull() method in Member.cfc:

public void function setGenderNull() {
  structDelete(variables, “gender”);
}

option 2: use setGender():

m = EntityLoad(“member”, memberID);
m.setGender(JavaCast("null", ""));

Notice that this is totally valid, but this is weird because I’m not really doing anything java, but I’m forced to use JavaCast() function, why?  There’s no ‘null’ value in CF!

Would you like CF to introduce NULL as a new reserved word?  Then we can finally do:

m.setGender(null);  

// CFML becoming more java?  What do you think?

6 comments:

  1. They need to do something. See this forum post about working with ORM and null:

    http://forums.adobe.com/thread/483080

    ReplyDelete
  2. Thanks iotashan.

    Ya, we got 'new' in CF9, why not 'null' too? :)

    ReplyDelete
  3. I have really been enjoying the isNull() method - much more than I thought I would.

    Introducing a NULL value, however, makes "nullness" much more concrete than it is now. Meaning, if we have a null keyword, then I assume we'd have to be able to compare things to null:

    if (xyz eq null){ .. }

    What happens here? Does this always return false since "xyz" doesn't exist (and therefore can't be compared)? Does it return true since xyz is null? Does it thrown an error since xyz cannot be referenced?

    Right now, the isNull() is a really nice short hand for structKeyExists()... but if we introduce NULL, then there is a fundamental shift.

    ReplyDelete
  4. @Ben Nadel, yes in that case, one must use IsNull(). However, the example you came up with is invalid for language like Java as well.

    if (undefinedVal == null) {}
    // this throws exception
    // in Java as well

    That is, if undefinedVal is really undefined, not a reference that references nothing, then Java will complain as well.

    ReplyDelete
  5. Ahh, right, true. However, in languages like Javascript, I believe you can reference KEYS off of objects and test them for nullness. Something like:

    if (window.foo == null){ .. }

    ... of course, in Javascript, you can also do this:

    if (foo){ .. }

    ... so maybe the Javascript comparison is moot.

    Only to say, they would *really* need to think it through if they introduced NULL.

    ReplyDelete
  6. Yes, they would.

    However, if they don't introduce Null, or think of a better solution to handle cases like this or iotashan's, the use of Javacast("null","") will be used everywhere throughout...

    And eventually, null will be added in like CF9.0.1 or something, then it is going to be troublesome. Like... how ppl are still using EQ when they can't remember when is "==" operator is introduced at which version.

    ReplyDelete