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: | Jul 18, 2009 4:54:19 am | |
| List: | net.java.dev.rococoa.users | |
On Jul 17, 2009, at 11:01 AM, Duncan McGregor wrote:
I'm canvassing opinion on Rococoa's handling of nil.
As I understand it, ObjC silently ignores messages sent to nil, whereas Java throws NullPointerException if you try to invoke a method on null.
That's a little simplistic:
http://www.cocoadev.com/index.pl?MessagingNilAndUniversalBinaries
I'm trying to decide what I think, but here is a taster of the issues - if you call a ObjC method that is defined to return an NSObject, and the returned value is actually nil, should that return a Java null, or an instance of our Java NSObject that has nil inside it?
If the latter, should invoking methods on the Java NSObject throw NullPointerException (they currently do - is anyone relying on that behaviour) or pass down to ObjC to be silently ignored?
Does anyone know what the Java/Cocoa bridge does?
I think you've got to go all the way one way or the other. The point of the behavior on Cocoa is to allow code like this to return null rather than null pointer exceptioning if there's a null anywhere in the chain:
User someUser = ... String name = someUser.getName().getFirstName(); or rather NSString *name = [[someUser name] firstName];
So if you want to do that, what you need to return is a Java proxy representing 'the nil object'. On that object, if you call any method that returns an object, it should return *itself*. (i.e. messaging nil always results in nil). If the return type is primitive, zero is probably the best option.
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.
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)