The problem with Objective C is, after they have this wonderful message-eating nil, they added this NSNull that brings the problem back. And since it's a superset of C, you get NULL for free too.
I don't think you understand what NSNull actually is. It's designed to behave as an empty placeholder object in collections that don't allow nil, nothing more.
C's NULL isn't an issue either, nil == NULL == 0, and isn't encountered in any of the contexts described by the article.
So, given a collection, how do you identify if an element is an instance of NSNull? You do what is essentially a type-check. To me, this negates the purpose of the message-eating nil. Not everywhere, as you seems to be reading, but where NSNull is used, which well, actually, can be anywhere, since we use lots of collections.
