Re: [Pyobjc-dev] Calling methods on nil

[Marcel W. <ma...@me...>]

On Sunday, May 11, 2003, at 03:49  Uhr, bb...@ma... wrote:

> 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'.

Having done ObjC development since 1987, I much prefer the coding 
simplicity the current behavior gives, while I don't recall the 
problems you report being anything but an extremely rare occurrence.

> 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.

Hmmm...this sounds like you are working too much with mutable state, in 
which case nils are just one symptom, and doctoring about with this one 
symptom is just hiding the deeper problems.  If you move away from 
mutable state, you will also find that you don't have problematic 
values (of which nil is just one prominent example) causing problems 
when the cause of the problem (of the problematic value) has long since 
disappeared from the call-stack.

If you use a more "functional" programming style, pulling values and 
evaluating expressions when needed instead of pushing values and 
stashing computed values, you will likely find that you don't get this 
type of problem-propagation.

> 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.

While I don't question your personal experience, I do believe that the 
problem may lie elsewhere.

Also, I believe very strongly in "intention-revealing" code.  That is, 
the code should reflect the problem, not the technology.  Things like 
constant checking of types/nil-values/exceptions typically have nothing 
to do with the problem domain, and do little but obscure the solution.  
I certainly notice that my Java code is a lot more verbose and a lot 
less maintainable than my Objective-C code.

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
ma...@me...		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.