New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace RACTupleNil with EXTNil #99
Comments
It's the "most intents and purposes" part that bothers me. It seems better in my mind to just use a sentinel and real |
It's really just identity checks and other methods which reveal it to be an actual object and not truly nil, but there's nothing to prevent mapping it to a real nil, like is done with RACTupleNil. It's mostly valuable in collections, so you can save and pull out values that actually behave as nil. |
Right, since we're almost always just mapping it to true My perspective is this. For consumers, |
What about RACTupleNil is superior to NSNull, then? |
Nothing, except that it's not |
I disagree. NSNull is used throughout Cocoa as "nil represented in a collection." In particular, that's how KVC/KVO treats it. |
Perhaps, but users could mean |
That would be user error, IMO, specifically because |
That's one use of
|
I don't really agree with that, but I think we're at an impasse, and it's not a big deal either way. |
I know that
RACTupleNil
was deliberately chosen overEXTNil
at one point, but I don't remember/understand the motivation for it.EXTNil
interoperates with code that expectsnil
orNSNull
, so is more "backwards compatible" in a certain sense. This same property also makes it nicer for things likeRACBlockTrampoline
, becauseEXTNil == nil
for most intents and purposes.The text was updated successfully, but these errors were encountered: