Re: [Pyobjc-dev] Calling methods on nil

[Just v. R. <ju...@le...>]

Marcel Weiher wrote:

> > The mechanics differ, but it's the same thing (OO with dynamic
> > method dispatching).
> 
> Exactly.  There is dynamic dispatch.  So when you "send a message",
> you get dynamic dispatch, and THEN the method is called.  If you just
> say "the method is called", you are simply *verbally* omitting the
> dynamic dispatch, though of course it is still happening.

That's just a matter of perspective <wink>: to me "the method foo of
this object" means the method you'd get when dispatching. Since dynamic
method dispatching is so deeply integrated in Python, I don't see how it
could mean anything else, so I disagree I'm omitting something crucial.

> > (I agree with you there's some implicity involved in method calling,
> > it's just that it doesn't feel that way to me since the rules are
> > clearly defined.)
> 
> Exactly my point, thank you!  :-)   The fact that it doesn't *feel* 
> like that any longer for you just shows how implicit message sending 
> (or dynamic dispatch, if you prefer) has become.
> 
> So it goes with ignoring messages to nil:  the rules are very clearly
> defined (a lot simpler than messages to other receivers), so there is
> no "general principle" that is being violated.  It is just that you
> are used to something different, and haven't assimilated these
> particular rules (yet ;-).

I'm not arguing against sending messages to nil in ObjC (although I
don't like it, see below), but against supporting it by PyObjC in
*Python*. In ObjC it makes more sense since all dispatching goes through
objc_msgSend(), so it can easily special-case nil. It simply doesn't
work like that in Python, but I've explained that before (in case you
missed it "bound method" is the key word).

(Just yesterday I was working on some code where a (Cocoa) method
unexpectedly returned nil (translated to None in Python). I was
extremely happy to get a traceback instead of silent failure; since None
is an actual object, it dispatches methods just like most other objects,
ie. raise an exception if a method isn't found. A silent failure surely
would've cost me much more time to figure out what I did wrong. Ignoring
messages to nil is convenient when you expect it, but it's a liability
when you don't. I much rather explicitly test for nil than shoot myself
in the foot.)

Just