> Say what ? Local variables show up perfectly fine in the
debugger. Creating an instance variable just to store intermediate
results is of dubious value.
Even with nested messages, no special magic is needed. To see intermediate values, just use the po command.
> po [NSURL URLWithString:@"somestring"]
> po [NSURLRequest requestWithURL:[NSURL URLWithString: @"somestring"]]
I also highly recommend F-Script for this type of interactive testing/debugging: http://www.fscript.org/
Meh. The moderators don't seem to think this is off-topic, so I'll
shove my opinion into some unspecified orifice and join in. Though I
think this part is suited to xcode-users, I'll bite:
Why put in the extra work for intermediate changes (especially if
you are monitoring a lot of changes in a tight loop of many
iterations) by typing po a million times? You can't see "[NSURL
URLWithString:@"somestring"]" for instance in your variable list
without it and typing it at each iteration is ridiculous. Even if you
automate it by setting an action at a breakpoint, the output is in the
run log and not at some useful place in your variable list. This is
*almost* as bad as using a crapload of NSLog() statements to debug and
skipping the debugger altogether, IMO. :-)
Don't get me wrong, Eric (I'm not meaning to be confrontational),
your method works, but it's just not as efficient as writing
easily-digested lines of code, the products of which show up in one
neat list, easily explored and modified with the GUI app you're using
for your development. In short, this is not a modern solution.
In the grand scheme, it costs you nothing to be verbose in this case
(using a variable) when your code is compiled. Unless you write
perfect code all the time, at some point you're going to need to debug
something that you've cleverly condensed from fifty lines into a
single line. If you've done so, kudos; you win the obfuscation prize.
Now try to debug it quickly and efficiently using a bunch of po's. ;-)
Not everything has to be spaced out and named like so:
NSString * string1 = @"Pedantic planning produces pathetic processes";
NSString * string2 = [string1 stringByAppendingString:@" posthumously
predicating pathetic procedures"];
NSString * string3 = [string2 stringByAppendingString:@" precluding
practical productivity"];
NSString * string4 = [string3 stringByAppendingString:@"."];
That would be ... prediculous. ;-) However, some small nested set of
commands that are easily-read and produce a well known object with a
set of at least fairly-well-known objects are about as deep as you'd
want to go so *visual* debugging is easier (with my apologies for the
lack of uniform e-mail fonts forcing me to put this all inline):
NSDictionary * d = [NSDictionary dictionaryWithObjectsAndKeys:[NSArray
arrayWithObjects:@"one", @"two", @"three", nil], @"stuff", [NSColor
redColor], @"roxanne", @"Microsoft", @"evil", nil];
Here we're creating several objects (one of which is a list of other
objects) in the middle of creating another object. This wouldn't be
quick and easy to visually debug (and I rarely do such things for that
very reason) but it's not that hard to pick apart if you find
problems. A simple drag-and-drop operation and a few typed characters,
followed by a click on the old fix-and-continue button and it's
magically an order of magnitude (figures approximate) easier to debug
visually. I wouldn't want to get too much more complicated than that
for fear of my "nest" becoming a "rat's nest".
My idiot $0.02.*
--
I.S.
* Idiot currency not good on any continent, island, body of water, or airspace.
_______________________________________________
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