8 messages in net.java.dev.rococoa.usersRe: nil| From | Sent On | Attachments |
|---|---|---|
| Duncan McGregor | Jul 17, 2009 8:01 am | |
| David Kocher | Jul 17, 2009 8:40 am | |
| Duncan McGregor | Jul 17, 2009 9:14 am | |
| David Kocher | Jul 17, 2009 3:52 pm | |
| Harald Kuhr | Jul 18, 2009 3:40 am | |
| Andrew Thompson | Jul 18, 2009 4:54 am | |
| Andrew Thompson | Aug 7, 2009 8:21 pm | |
| Duncan McGregor | Aug 10, 2009 8:00 am |
| Subject: | Re: nil | |
|---|---|---|
| From: | Duncan McGregor (dun...@oneeyedmen.com) | |
| Date: | Aug 10, 2009 8:00:31 am | |
| List: | net.java.dev.rococoa.users | |
On 8 Aug 2009, at 04:22, Andrew Thompson wrote:
On Jul 18, 2009, at 7:54 AM, Andrew Thompson wrote:
Or you go the other way, obey Java semantics and just return null as soon as we see a nil. That'll obviously NullPointerException as soon as it is used.
Returning an NSObject with nil inside is almost the same thing, because you can't use it without getting an exception, but to a Java programmer if getFoo() returns null, Foo x = getFoo() should result in x being null, not x being an object that NullPointers when it is used.
Or as I said, go the other way and actually make it work like Objective C ... return an object "NSNil" that returns 'this' whenever any method with an object return type is called.
The later allows people to "port" code from Cocoa more naturally, the former is the least surprising to Java programmers. The current halfway house seems less than ideal.
What did you decide for this in the end Duncan? As I said, I think either end of the spectrum could make sense, with a slight preference for just returning null. The middle ground is the hardest to be comfortable with for me.
To the extent that we had a middle ground, it was my mistake rather than policy. The policy is now that we return nil, er null. If you find anywhere that isn't true, please let me know.
D