Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

nil, Nil, NULL, NSNull

nshipster.com

Post reply on HN
Print view View original

11–20 of 66 posts

Re: nil, Nil, NULL, NSNull

#11

Post by mpyne »

Nice article, but I just wanted to throw out that if being able to call a class method on a null object in C++ is desirable, you can actually check for that condition instead of just crashing.

    if(!this) return false; // Or whatever
Of course it's open for debate as to whether this is something to encourage, but it can help from having to use a Null Object pattern in some situations.

Re: nil, Nil, NULL, NSNull

#12

Post by [deleted] »

matttthompson wrote: post #8
mikeash wrote: post #2

Good article overall. However, I must object to this bit: "C represents nothing as 0 for primitive value" That's not true. There is no "nothing" for integer types, and floats either also lack "nothing", or have NaN as their "nothing", depending on your perspective. One of the (many) annoying features of C-style NULL is that it means that some types are effectively option types while other types aren't, and there's no…

To clarify: I mean to say that 0 represents "nothing" in C in the same way that it does in math. This is one of the things I love about C--the ability to exploit the properties of numbers directly, rather than needing to build abstractions around them. Bitmasks, for example, are one of my favorite things ever. But yeah, point well-taken. Perhaps I'll take the opportunity to wax on the other special values used in Fou…

[deleted]

Re: nil, Nil, NULL, NSNull

#13

Post by ajanuary »

SeanLuke wrote: post #3

> In other languages, like C++, this would crash your program, but in Objective-C, invoking a method on nil returns a zero value. This greatly simplifies expressions, as it obviates the need to check for nil before doing anything: // For example, this expression... if (name != nil && [name isEqualToString:@"Steve"]) { ... } // ...can be simplified to: if ([name isEqualToString:@"steve"]) { ... } Wow, that is some bad…

You do raise an interesting point that a nil swallowing language forces you to write your methods in such a way as to logically return false for a nil receiver.

I'd argue this is the way most methods are naturally written, so it doesn't have too much of an impact.

I'm struggling to think of an example where logically returning true for a nil receiver is a much more natural than the other way around. Most of them, including your example of isEqualToString vs. isDifferenceFromString, are at best equal.

It's probably something that should be made more explicit in discussions about nil swallowing, such as the OP.

Re: nil, Nil, NULL, NSNull

#14

Post by kstenerud »

SeanLuke wrote: post #3

> In other languages, like C++, this would crash your program, but in Objective-C, invoking a method on nil returns a zero value. This greatly simplifies expressions, as it obviates the need to check for nil before doing anything: // For example, this expression... if (name != nil && [name isEqualToString:@"Steve"]) { ... } // ...can be simplified to: if ([name isEqualToString:@"steve"]) { ... } Wow, that is some bad…

Why is it bad code? If name is nil, isEqualToString will return false. And that's correct behavior because nil is not equal to the string @"steve".

Re: nil, Nil, NULL, NSNull

#15

Post by judofyr »

ajanuary wrote: post #13
SeanLuke wrote: post #3

> In other languages, like C++, this would crash your program, but in Objective-C, invoking a method on nil returns a zero value. This greatly simplifies expressions, as it obviates the need to check for nil before doing anything: // For example, this expression... if (name != nil && [name isEqualToString:@"Steve"]) { ... } // ...can be simplified to: if ([name isEqualToString:@"steve"]) { ... } Wow, that is some bad…

You do raise an interesting point that a nil swallowing language forces you to write your methods in such a way as to logically return false for a nil receiver. I'd argue this is the way most methods are naturally written, so it doesn't have too much of an impact. I'm struggling to think of an example where logically returning true for a nil receiver is a much more natural than the other way around. Most of them, inc…

`[a compare:b]` returns 0 both if they are equal and if a is nil.

Re: nil, Nil, NULL, NSNull

#16

Post by tyler-dodge »

judofyr wrote: post #15
ajanuary wrote: post #13

Earlier quoted context omitted.

You do raise an interesting point that a nil swallowing language forces you to write your methods in such a way as to logically return false for a nil receiver. I'd argue this is the way most methods are naturally written, so it doesn't have too much of an impact. I'm struggling to think of an example where logically returning true for a nil receiver is a much more natural than the other way around. Most of them, inc…

`[a compare:b]` returns 0 both if they are equal and if a is nil.

True, although none of the other return values make that much sense with nil either.

Re: nil, Nil, NULL, NSNull

#17

Post by to3m »

ajanuary wrote: post #13
SeanLuke wrote: post #3

> In other languages, like C++, this would crash your program, but in Objective-C, invoking a method on nil returns a zero value. This greatly simplifies expressions, as it obviates the need to check for nil before doing anything: // For example, this expression... if (name != nil && [name isEqualToString:@"Steve"]) { ... } // ...can be simplified to: if ([name isEqualToString:@"steve"]) { ... } Wow, that is some bad…

You do raise an interesting point that a nil swallowing language forces you to write your methods in such a way as to logically return false for a nil receiver. I'd argue this is the way most methods are naturally written, so it doesn't have too much of an impact. I'm struggling to think of an example where logically returning true for a nil receiver is a much more natural than the other way around. Most of them, inc…

A container might have an isEmpty function, and if the pointer is nil, that is probably more empty than not empty (though personally I don't believe either answer makes sense). "[x isEmpty]" might be more appropriate than "[x count]==0" for a list-type container.

I always check for nil explicitly, personally. It sidesteps any question of whether the method makes sense in the nil case. And sending messages to nil can't work in general, because the return value could be a struct.

Re: nil, Nil, NULL, NSNull

#18

Post by nicholassmith »

SeanLuke wrote: post #3

> In other languages, like C++, this would crash your program, but in Objective-C, invoking a method on nil returns a zero value. This greatly simplifies expressions, as it obviates the need to check for nil before doing anything: // For example, this expression... if (name != nil && [name isEqualToString:@"Steve"]) { ... } // ...can be simplified to: if ([name isEqualToString:@"steve"]) { ... } Wow, that is some bad…

No snark: could you explain why it's bad code for you?

Re: nil, Nil, NULL, NSNull

#20

Post by jfb »

to3m wrote: post #17
ajanuary wrote: post #13

Earlier quoted context omitted.

You do raise an interesting point that a nil swallowing language forces you to write your methods in such a way as to logically return false for a nil receiver. I'd argue this is the way most methods are naturally written, so it doesn't have too much of an impact. I'm struggling to think of an example where logically returning true for a nil receiver is a much more natural than the other way around. Most of them, inc…

A container might have an isEmpty function, and if the pointer is nil, that is probably more empty than not empty (though personally I don't believe either answer makes sense). "[x isEmpty]" might be more appropriate than "[x count]==0" for a list-type container. I always check for nil explicitly, personally. It sidesteps any question of whether the method makes sense in the nil case. And sending messages to nil can'…

I dunno. I think a nil container is neither empty nor full, it's nil. But trying to reason about 3VL in an environment that doesn't support it is … trying.
Post reply on HN