Re: Learning the Interface Builder
Re: Learning the Interface Builder
- Subject: Re: Learning the Interface Builder
- From: Jean-Denis MUYS <email@hidden>
- Date: Fri, 04 Nov 2011 16:10:32 +0000
- Thread-topic: Learning the Interface Builder
On 4 nov. 2011, at 16:14, Matt Neuburg wrote:
> On Thu, 03 Nov 2011 18:46:13 -0700, Conrad Shultz <email@hidden> said:
>> A great many bugs
>> early on will likely owe to sending messages to nil
>
> It occurs to me (moving slowly but surely off-topic here) that the ARC people missed a trick with this one. One of ARC's most wonderful side-benefits is that it guarantees that any object pointer, strong or weak, that is not pointing to an object, is pointing to nil - because ARC puts it there. This suggests that there could have been a compile switch where what ARC puts there is an object that behaves like nil but also logs "You sent a message to nil" to the console. In fact, ARC could also substitute this object when you assign nil to something in your code. (It already does so much messing with your code that this little addition would be easy.) Then we could really track down those accidental send-to-nil moments.
>
> Is that a wild and crazy idea or what?
>
> m.
This is not really crazy, but not very useful as there are *tons* of messages sent to nil everywhere.
In any case, there is already a mechanism in the Objective-C runtime to intercept - and then logging - messages to nil:
id _objc_setNilReceiver(id newNilReceiver);
This function is not public, but you can find it in the source code of the objective-C runtime. Simply declare it as an extern function.
Since this is undocumented and unsupported, it is subject to change any time and can only be used for debugging purpose (if at all). But that was your intent right?
Jean-Denis
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden