RE: [OT] Re: Cocoa and messages to nil, revisited
RE: [OT] Re: Cocoa and messages to nil, revisited
- Subject: RE: [OT] Re: Cocoa and messages to nil, revisited
- From: Jeff Laing <email@hidden>
- Date: Thu, 9 Aug 2007 09:19:15 +1000
Once again, someone decides to preface this all with [OT] making people
thing its off-topic so I'm going to kill this thread *in my head* and never
reply again, but sorry, listMom, I have to answer this.
> It's very unlikely that you will ever need
> the extra performance, or indeed that you would gain overall if you
> used this pattern throughout your application. But rather than
> assuming, let's test it. Here are some numbers:
<mild sarcasm>
You know, on my machine, it was 10 orders of magnitude slower. Gosh, why
was that?
Oh wait, I remember.
I HAVE A NIL OBJECT RECIEVER INSTALLED, WHICH THE LANGUAGE CLEARLY ALLOWS ME
TO DO.
</mild sarcasm>
The COCOA framework gets used by lots of different applications, and it
clearly penalizes some of those application, by wasting its own time.
Granted if you are going to benchmark, you need to benchmark real
application use - and when benchmarking a framework, you need to benchmark
*typical* applications, not those with debug code left in, which is what I
have.
> Are one in six message sends in a typical application to a nil
> object? I doubt it. How about more than one in seventeen? It's
Did you actually try using my code? You don't need to *doubt* it, you can
see them going past. And its not a high percentage - I didn't say it was.
But any number > 0 is probably one of the contributing reasons why I get
that spinning beachball on my old Bondi iMac, which yes does otherwise run
OSX just fine.
> possible, but in high-performance code (the only place this kind of
> saving would ever matter) it seems unlikely.
On this I agree. But its a bad habit to develop.
> Even if you removed the nil checks from the ObjC runtime, you're only
I did *not* propose removing the nil checks from the runtime at any time. I
proposed installing a listener that reported messages sent to nil, so that a
developer could debug his application quicker.
> going to make the non-nil message sends faster by a *tiny* amount,
> and for what? You're going to have to add tests *all over
> the place* for nil,
This is a conclusion from an invalid premise. I'm not removing the test
from the runtime.
I am going to add the tests in the places where I know I was being lazy, and
and reports which should will be a potential bug.
> So all you've done is made it
> more likely that the end user will lose their data when a nil does
> turn up unexpectedly... whereas your program might have behaved
> oddly, but would probably have let them save their work, it will now
> crash instead.
This is a conclusion from an invalid premise; I'm not preventing you from
sending messages to nil at the runtime level. My code won't crash any more
than yours will.
> you'll now be paying a penalty because branch prediction won't work
> as well with your thousands of "if" statements as opposed to the one
> branch in the runtime.
Branch prediction is only going to be affected if I'm sending messages to
the exact same nil thousands of times in a row - if the CPU seriously
decides that 'the last time he compared two values, he got nil so he'll
probably get it this time as well', then all hope for humanity is lost.
> Anyway, I think the above demonstrates more than adequately that
> there is no credible performance argument for what you're
> proposing.
I didn't *give* a performance argument - I said that it would have been a
useful development tool, if it hadn't been effectively nobbled by Cocoa.
The parenthesised note about how it seemed like a performance hit as well is
whats triggered this sidetrack.
> It *is* an Objective-C language issue, because it's a design
> *feature* of the language that sending to nil is a no-op. It didn't
> get that way by accident; it was designed that way so it could be
> used exactly how Cocoa programmers (and the Cocoa frameworks) *are*
> using it.
Sorry, the language is *designed* to allow the installation of a nil message
handler - I don't need to discuss that with the language designers, with the
possible exception of saying "well, doesn't it suck that the language
appears to have this really neat feature and Cocoa makes it unusable".
There is *nothing* you can do inside Objective-C to make this feature useful
in Cocoa - the change has to be made in Cocoa. Which is why I believe its
on-topic for the Cocoa list, and almost completely irrelevant to the
language list.
I *have* thought about how relevant my postings are to the list I'm mailing
to, despite some of the replies I've received.
> Even if it was a style issue, and even if you hadn't already been
> told that it was off topic, it would still be obnoxious of you to
> post it to the Cocoa list because style "issues" are the kind of
> thing likely to trigger an argument.
The whole thing was started from a discussion of 'fluent style' where
someone thought that the fluent style of coding:
[obj1 doSomethingWith:[obj2 obj2WithArgs:...],[obj3WithArgs:...],
...]
was a good thing and I pointed out that no, it was not a good style if you
wanted to do any form of error checking. Which got on to 'Cocoa chooses to
represent failure by returning nil, rather than throwing exceptions' (both
of which are available in the language).
So I didn't start the style discussion, I merely pointed out why its a bad
thing, particularly in a Cocoa context. Now I could have said "we don't
talk about the style the Cocoa examples use here, thats an objective-C
issue" which would be technically correct (the best kind of correct) but
ludicrous in context.
> The discussion about nil moved to the objc-lang list four days ago
> (and has since mutated into a discussion about the pros and cons of
> exceptions). You're most welcome to join in on that list if you like.
Seriously, I'm not interested. What I presented in my post was a snippet of
code that Cocoa programmers could use to help them debugging Cocoa problems
using what appears to be a fairly common Cocoa coding style. Objective-C
coders who don't use Cocoa probably already know that stuff.
> If this is happening to you a lot, you are doing something wrong.
> The most common reasons for this problem that I can think of are (a)
> where you've declared e.g. an NSMutableArray member variable and
> never actually initialised it, and (b) not connecting things in nib
> files.
Or the dictionary I loaded from a plist is from an old version
Or the file I thought was out there isn't
Or the user has changed his name, which was being used as a key somewhere
Or a group is no longer in the address book
You are trying to second guess the problem coding constructs and saying
"look more carefully when you do X". I am bemoaning the fact that, if Cocoa
did things slightly differently, I could have the computer do the looking
for me at *every* call. And none of you need care because it could only
have a positive impact on you.
> p.s. To the rest of the people on the list: my apologies if this is a
> bit long.
And as I said at the onset, I am now going silent on this topic. Anyone who
cares will have taken my code snippet for what it was worth. Anyone who
doesn't probably already has a key-binding that inserts
NSAssert(x!=nil,@"how the hell did x become nil");
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden