Re: [Pyobjc-dev] Calling methods on nil

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

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

> On Sunday, May 11, 2003, at 11:49 US/Eastern, Marcel Weiher wrote:
>>> 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.
>
> Difference in experience then --

Obviously.  It begs the question:  why are you experiencing these 
problems?  It can't really be message-eating nil by itself, because 
then I should be experiencing those same problems.  But I am not.

>  I have spent a good part of my career mentoring teams to help them 
> achieve success.

Good for you!  Maybe that is why you are experiencing those problems 
and I do not, because you help with success and I only help with 
failure...

>   This is typically done in environments where the project is under 
> "schedule stress".  More often than not a major source of stress is 
> "strange or intermittent failures".

Lucky you!  I only wish my major sources of stress were something I had 
control over.

My sources of "stress" are usually somewhat more external, like a 
customer whose customer is about to pull the plug on them because their 
3rd attempt at delivering a content management system also failed, and 
now they've come to us and we have 3 days to get the system running 
when we had planned for another couple of months.  With the added 
stress that my master's thesis for university is due that same week 
(that was fun!)  Or arriving at a trade show to find that the equipment 
you've been provided doesn't actually work, and you have to re-write 
the RIP software for tomorrow morning...well, actually for later 
today...things like that.

> If you have a construct like...
>
>     [[[[foo bar] baz] bob] fred];
>
> ... and any one of -bar, -baz, -bob, or -fred unexpectedly returns nil 
> when it shouldn't, debugging is a nightmare.

Really?  Actually, debugging such deeply nested expressions with gdb 
really is a pain, but this also has nothing to do with nil-eating or 
not nil-eating.  It has to do with deeply nested expressions and the 
difficulty of setting breakpoints within such an expression.

>>> 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.
>
> No -- that is not the problem.

Objection:  if you are "...many cycles through the run loop away..." 
then you are *definitely* having a problem with propagating incorrect 
values in mutable state.  Unless you have found a magical method of 
keeping temporary variables around between event-loop cycles 
(cyrogenics? ;-)

> There is the potential for the problem to arise *anywhere* a method is 
> invoked/called/messaged where the developer has not previously 
> validated that the target is non-nil.

Well, otherwise it is even worse.  You have the chance of an exception 
messing you up despite the fact that there may not actually be a 
problem.  For example, to be safe, the simple line of code above would 
have to check for nil before every message send:

[[[[foo bar] baz] bob] fred];

if ( foo!=nil ) {
	id temp1=[foo bar];
	if ( temp1 != nil ) {
		[temp1 baz];
		... and so on ...
	}
}

Why?  Well, if nil is a problem in the code-snippet, then it is 
obviously unexpected.   Otherwise, it would either be handled or 
ignoring it would be OK.  However, if it is unexpected, then you can't 
say which message-send will return nil "unexpectedly"...

[snip]

>> 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.
>
> It would seem that "intention revealing" would mean writing code that 
> shows that the developer intended to deal with the fact that something 
> could potentially be nil in a valid situation by actually checking for 
> it.

That turns out not to be the case.  "Intention revealing" means that 
you reveal what the *intent* of the code is.  Error-handling is 
*implementation*, because I am sure it is not your intention to cause 
errors...well, I *hope* it isn't ;-)

[snip]

Anyway, I am fairly confident that this discussion has outlived its 
usefulness.  I have no problem with you preferring "raising-nil" if 
that helps you and your colleagues/clients.  I just want to point out 
that the problems you seem to have experienced are not universally 
shared, and it is therefore quite reasonable to come to different 
conclusions.

Marcel

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