nil, Nil, NULL, NSNull • Hacker News Board

Re: nil, Nil, NULL, NSNull

#21

Post by efnx » Mon, Jan 07, 2013, 5:57 PM UTC

optymizer wrote: post #10

efnx wrote: post #9

Earlier quoted context omitted.

That's not bad code, you must be sarcastic. I've never heard of the method isDifferentFromString: and besides, the method name suggests it's the same thing as isEqualToString: approached from the other side. Are you referring to the capitalization mistake in @"steve"? When using sarcasm keep in mind there's no tone in text ;)

Well, if you've never heard of it then it cannot exist and that invalidates his example, right? I'm not saying the example is correct, I'm pointing out that "I've never heard of it" / "Works on my computer" are dangerous attitudes to have.

I'm sorry, I should have been more clear. I meant "I've never heard of that method, so I looked it up in Xcode and it turns out it is not a method on NSString (and why should it be if !isEqualToString: achieves the same purpose?) which leads me to believe that this comment is sarcasm, if it isn't can you please clarify?"

Re: nil, Nil, NULL, NSNull

#22

Post by micampe » Mon, Jan 07, 2013, 6:02 PM UTC

seanalltogether wrote: post #4

Also for what its worth, variable declarations are not nil by default, this bug tied me up for quite some time. NSString *val; if(something){ val = @"hello"; }else if(somthingelse){ val = @"goodbye"; } if(val){ [self display:val]; } this can send you on a wild goose chase for not declaring val = nil initially.

And, if you don’t or can’t use ARC, turn on -Wuninitialized or use the static analyzer (clang warns on uninitialized values only with -Wall).

Re: nil, Nil, NULL, NSNull

#23

Post by alayne » Mon, Jan 07, 2013, 6:18 PM UTC

efnx wrote: post #9

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…

That's not bad code, you must be sarcastic. I've never heard of the method isDifferentFromString: and besides, the method name suggests it's the same thing as isEqualToString: approached from the other side. Are you referring to the capitalization mistake in @"steve"? When using sarcasm keep in mind there's no tone in text ;)

He's not being sarcastic. Maybe a better example of what he is trying to get at is

if (![missleLauncher isDisabled]) { /* declare thermonuclear war */ }

When missleLauncher is nil, thermonuclear war is still declared which may not be the programmer's intent.

Re: nil, Nil, NULL, NSNull

#24

Post by xsmasher » Mon, Jan 07, 2013, 6:28 PM UTC

alayne wrote: post #23

efnx wrote: post #9

Earlier quoted context omitted.

That's not bad code, you must be sarcastic. I've never heard of the method isDifferentFromString: and besides, the method name suggests it's the same thing as isEqualToString: approached from the other side. Are you referring to the capitalization mistake in @"steve"? When using sarcasm keep in mind there's no tone in text ;)

He's not being sarcastic. Maybe a better example of what he is trying to get at is if (![missleLauncher isDisabled]) { /* declare thermonuclear war */ } When missleLauncher is nil, thermonuclear war is still declared which may not be the programmer's intent.

Properties and methods are given "positive" names as a matter of convention, and to make reasoning about Nil easier.

In Objective-C, the question "should I name my method isEnabled or isDisabled?" has a reasonable answer - you consider what makes most sense (or any sense) when called on Nil.

This is probably a good rule for other languages too - "negative" booleans can lead to double-negatives and unreadable code.

Re: nil, Nil, NULL, NSNull

#25

Post by mikeash » Mon, Jan 07, 2013, 6:28 PM UTC

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…

0 isn't really "nothing", though. It's special, in that it's the additive identity of a lot of useful sets of numbers, but it's definitely something. An integer containing 0 is completely different from a pointer containing nil, conceptually speaking. To really have "nothing", you could use an int*, where a NULL pointer means "nothing", and a valid pointer means it contains a value. Or something more efficient with e.g. a separate flag. But in any case there's no real native support in the language for the concept.

Re: nil, Nil, NULL, NSNull

#26

Post by aaronblohowiak » Mon, Jan 07, 2013, 6:29 PM UTC

j_baker wrote: post #19

It's worth noting that Go has interesting handling for empty values as well. A nil basically means "the zero value for a given data type". Thus, an empty array compares equal to nil: http://tour.golang.org/#36

This is consistent with the set-theory perspective of null ( ∅ )

Re: nil, Nil, NULL, NSNull

#27

Post by ajanuary » Mon, Jan 07, 2013, 6:33 PM UTC

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.

Cheers for the counter-example.

I can't think of a compare method in the Objective-C core lib (the biggest nil-swallowing lib I know of). Does anyone know of one? Would be interesting to see how it's handled and if it causes issues.

You could return an enum, which would allow you to use non-obvious values (Lower = 1, Equal = 2, Higher = 3), though this would make it a bit of a pain to interface with C-style libs.

Obviously the presence of a work-around doesn't mean nil-swallowing is a good idea, but rather cements the idea that library authors need to put in extra effort to make sure nil receivers are handled appropriately.

Re: nil, Nil, NULL, NSNull

#28

Post by xsmasher » Mon, Jan 07, 2013, 6:38 PM UTC

seanalltogether wrote: post #4

Also for what its worth, variable declarations are not nil by default, this bug tied me up for quite some time. NSString *val; if(something){ val = @"hello"; }else if(somthingelse){ val = @"goodbye"; } if(val){ [self display:val]; } this can send you on a wild goose chase for not declaring val = nil initially.

That's a rule of C; stack vars are not initialized. Same thing would happen with an int.

Member variables of a class are set to zero by (init or alloc? can't remember.)

Re: nil, Nil, NULL, NSNull

#29

Post by scrumper » Mon, Jan 07, 2013, 6:38 PM UTC

Any use cases for Nil, that is, the class pointer to nothing? I've not seen it in the wild (which isn't saying a great deal.)

Re: nil, Nil, NULL, NSNull

#30

Post by ajanuary » Mon, Jan 07, 2013, 6:46 PM UTC

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'…

Cheers for the counter-example.

I agree there isn't really a sensible answer for [nil isEmpty].

There are two uses of isEmpty I can think of.

    if ([container isEmpty]) {
        [container addItem:item];
    }

We want to add an item to an empty container. If it's nil, we don't add an item to it; that seems okay.

    if (![container isEmpty]) {
        Item item = [container getItemAt:0];
        [item doSomething];
    }

We check there will be an item before we get a value out of it. This one would cause issues.

NSArray doesn't have an isEmpty method. I wonder if this is one of the reasons why, or if it's just something like wanting to keep the interface small.

[Edit] You can of course invert the logic. Using [container hasItems] in the two examples above would function just fine. While isEmpty seems to be the variant used everywhere, hasItems doesn't seem too unnatural.