> 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 protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
