| 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: | David Kocher (dkoc...@cyberduck.ch) | |
| Date: | Jul 17, 2009 8:40:11 am | |
| List: | net.java.dev.rococoa.users | |
On 17.07.2009, at 17:01, 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.
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?
It should definitly return null. It makes programming against the API a lot more intuitive than to check for isNil() on the NSObject. See my patch sent to the dev list for NSInvocationMapper.
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?
Yes, I would expect that.
Does anyone know what the Java/Cocoa bridge does?
It maps nil to null.





