On Sat, 17 Mar 2012 01:45:33 -0700, G S <stokest...@gmail.com> said: >> >> This pattern is pretty questionable though in terms of OO — you have one >> class (NSNib, UINib, etc.) directly setting instance variables in another >> class (your view controller) and using runtime functions to hack around >> things like @private. >> > >How do you figure? I'm not doing any manipulation of non-property members >between classes. If you're saying that Cocoa does it when loading from a >nib, then it's doing that anyway; properties aren't required for that >action. From the end-user (end-programmer) perspective, I don't see any >bad OO going on here.
So we're talking about just declaring an IBOutlet ivar and letting the nib set it via KVC (in iOS)? The problem with that is that before ARC you could really mess yourself up with that pattern, as there is an **implicit retain** performed by KVC when it access an ivar directly, which you're not told about and which may not be at all what you want. So you've got this: IBOutlet MyClass* myIvar; ...just sitting there, with *no* retain policy declaration and thus nothing to remind you that you need to release that ivar in your dealloc or it's going to leak. For all the faults of @property declarations (well discussed in a different thread on this list), they are certainly helpful for reminding you, the programmer, how memory is supposed to be managed thru the accessor. And before ARC you could say this: @property (nonatomic, assign) MyClass* myIvar; ...and synthesize the accessors, and by jingo this would actually *be* an assign-policy setter (no retain), which, for something loaded from a nib, is very often what you want. So the property declaration actually **guards against KVC interfering with your memory management**. Therefore, my current pattern is to declare my nonpublic properties in a class extension in the .m file. This is so common that in Xcode 4.3 the iOS project templates actually give you a class extension in the .m file so you can do that - though, to be sure, the templates do some other memory management stuff that I don't agree with. Now, of course with ARC things are greatly simplified, and they're going to be simplified even more when synthesis of accessors is the default. Also I wish nonatomic were the default, but that's another story I suppose... m. -- matt neuburg, phd = m...@tidbits.com, <http://www.apeth.net/matt/> A fool + a tool + an autorelease pool = cool! Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
