And then there is NSNULL.
While on the subject, I would just like to warn ASOC coders of a potential “gotchas” that I myself have stumbled on a few times:
In lists that have become NSArrays you may be certain to have supplied a ‘missing value’ as one of the elements, but when you use it, it simply won’t work, and an obscure error message quibbles about ‘NSNULL’, and you may think it is the same as missing value, since that is what you supplied. However, searching the documentation reveals:
So, NSNull is an object and not a value, so it fails on tests for ‘missing value’ (which you thought it really was).
In the log output, you may see 2 different “kinds” of null:
(null)
The first one is the NSNULL object, whereas the second one is the null value which in ASOC can be treated as ‘missing value’. They don’t equate. It’s really irritating.
One simple way to “fix” this is to simply coerce the NSArray back to a list (. as list) which resurrects ‘missing value’ from NSNull. The following illustrates it:
set a to {missing value}
set b to current application's NSArray's arrayWithArray_(a)
log b's objectAtIndex_(0)
log item 1 of (b as list)
--> <null>
--> (null)
This crutch may be ok for small stuff, but if the list is large, there is a significant performance penalty, so other methods would be preferred.
I’m sure others on this forum could provide other (better) workarounds – I just would like to highlight the potential problem, since it can be really time consuming to find out what the problem is, especially if that ‘missing value’ is very infrequent.
PS: Maybe this would be a good thing to include in Shane’s excellent book on gotchas?