Re: What's the point of @properties?
Re: What's the point of @properties?
- Subject: Re: What's the point of @properties?
- From: Chris Hanson <email@hidden>
- Date: Mon, 20 Sep 2010 03:47:31 -0700
On Sep 20, 2010, at 3:30 AM, Stefan Nobis wrote:
> Bill Bumgarner <email@hidden> writes:
>
>> Thus, with the latest bleeding edge compiler, all you need is the
>> @property() (and cleanup in -dealloc) to declare a fully KVO
>> compliant attribute of your class.
>
> Is this also supported by the debugger? In XCode 3.x I once tried to
> omit the iVars but that's not very funny to debug (as it's hard to
> inspect the property values without manually declared iVars).
Instance variables are just one way of providing backing storage for a property. Core Data, for example, provides its own mechanisms. You could also do something similar for your own classes. Or you can have properties that expose state which is entirely dynamic, and not backed by any storage of its own (such as the count of a collection).
Thus to inspect the property, you need to actually run the getter to access the property. (With, alas, all the caveats that implies.)
GDB doesn’t support dot syntax for invoking property getters, so you just need to use bracket syntax when doing it:
// Code:
@interface Account : NSObject
@property (readwrite, copy) NSString *name;
@property (readwrite, getter=isEnabled) BOOL enabled;
@end
// While debugging:
(gdb) po [someAccount name]
(gdb) print (BOOL)[someAccount isEnabled]
If you’re using automatic or manual ivar synthesis, the default name is the same as the ivar, so with a little bit of work you can get the ivar values in gdb:
(gdb) po object_getIvar(someAccount, class_getInstanceVariable([someAccount class], "name")
(gdb) print *((BOOL *)((void *)someAccount + ivar_getOffset(class_getInstanceVariable([someAccount class], "enabled")))
(Note: Written in Mail, so there may be casting etc. that the above needs to actually work.)
Something like that should work well enough to encapsulate in a debugger macro, if someone so desires.
-- Chris
_______________________________________________
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