Re: [Pyobjc-dev] Calling methods on nil

[<bb...@ma...>]

On Sunday, May 11, 2003, at 05:46 US/Eastern, Ronald Oussoren wrote:
> This is the most important reason for not having a 'nil' object that 
> behaves ignores all method calls. Implementing such an object is easy 
> enough, but it is too easy to mis actual errors this way. And IIRC 
> this feature doesn't even work perfectly in Objective-C (what if the 
> method returns anything other than an 'id', like a 
> float/double/struct).

Having done ObjC development since 1989 -- 4 or 5 years prior to diving 
into Python -- you might be surprised to learn that I very strongly 
prefer the behavior of Python's (and Java's) 'message to nil throws' 
behavior vs. ObjC's 'message to nil silently eaten'.

When everything is working correctly 'message to nil silently eaten' is 
a great convenience.  When something somewhere unexpectedly returns 
nil, it becomes an incredibly nasty pain to try and figure out exactly 
where the problem might be.   By the time it crops up, you may be many 
cycles through the run loop away from where the problem actually is.

Over the last-- jeez, nearly 15 years-- I have seen novice and 
experienced developers-- myself included-- waste many many hours trying 
to track down a problem that turned out to be an unexpected nil.   
Going with a 'message to nil raises' model may have required the 
addition of quite a few extra if () statements here and there over the 
years, but that route would have considerably decreased the frustration 
factor for quite a large number of developers.

Even though objc_msgSend() supports the other dispatch model, you can't 
mix and match within a single application for obvious reasons.

In the context of PyObjC, I consider 'message to nil throws' to be a 
feature (and not just because it is the Python way).

b.bum