On Wed, Nov 19, 2008 at 5:41 PM, mmalcolm crawford <[EMAIL PROTECTED]> wrote: > > On Nov 19, 2008, at 2:29 PM, Michael Ash wrote: > >> On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford <[EMAIL PROTECTED]> >> wrote: >>> >>> On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote: >>>> >>>> (This is the one thing I hate the *most* about properties - they really >>>> feel glued on, at this point, rather than being a language feature that >>>> the "whole compiler" knows about) >>> >>> It's not clear how this is relevant to the implementation of dealloc? >> >> Because there's essentially no good way to dispose of properties given >> the way that they're implemented. >> > I'm not sure why this is the case? > You send a release message to instance variables for which there is a > corresponding retain or copy property.
This does not qualify as "good" in my book. A fundamental of good programming is "once and only once". You've now described the semantics of these properties in two different places in your code and, worse, one of those places is implicit rather than explicit. >> If you set them to nil, then you fall afoul of overridden setters and the >> like. >> If you manually release them, then you explode if you later change the >> property from assign to retain or vice versa. >> > But you have the same problem without properties. > Except that it's worse; you could change the implementation of an accessor > method (to assign rather than retain, for example), and you'd have no > cross-check to make sure you then did the right thing in dealloc. > > With properties, you have a clear set of statements that publicly declare > what are the memory management semantics, and you can cross-check them with > your dealloc method. This is true but I don't really see the point. I never said properties were worse than manual accessors, just that this omission really hurts their utility. >> There should be a way to take advantage of the built-in property >> mechanism to simply say "do the right thing for this property", >> ideally in a single call for an entire class, or even better yet >> wholly automatically as part of NSObject's -dealloc implementation or >> something. >> > That certainly might be a welcome feature -- I'd encourage you to file an > enhancement request. Duly noted. >> But instead, you get good support for synthesized setters >> and getters but once you step into -dealloc you're back on your own, >> losing a big part of the advantage, at least if you aren't willing to >> hold your nose a bit and simply set them to nil despite the warnings >> against it. >> > Again, this doesn't seem like a regression, it's just something that could > perhaps be taken advantage of. You've had to put up with worse up until > now. I'm honestly not sure why you're using the word "regression". Certainly I never said it was one, and I don't believe Mr. Laing meant to imply such either. Mike _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
