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: | Andrew Thompson (lord...@mac.com) | |
| Date: | Aug 7, 2009 8:21:52 pm | |
| List: | net.java.dev.rococoa.users | |
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.
AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside
(see you later space cowboy, you can't take the sky from me)