One other advantage to using properties over direct ivar access internally is KVO compliance.
Usually I prefer to declare properties backed by ivars of a different name, then use getters/setters everywhere except inside initializers and dealloc. Frees me from having to worry about willChangeValueForKey:, etc. I do this even if I currently don't observe a property in order to foster forward compatibility. (Sent from my iPhone.) -- Conrad Shultz On Nov 16, 2011, at 2:19, Quincey Morris <[email protected]> wrote: > On Nov 16, 2011, at 01:00 , Don Quixote de la Mancha wrote: > >> Using properties significantly increased the size of my executable >> file. If I had something like this: >> >> float a = [self foo: self.scale]; >> float b = [self bar: self.scale]; >> >> I could cut down the size of my code quite a bit by caching the return >> value of self.scale: >> >> float theScale = self.scale; >> float a = [self foo: theScale]; >> float b = [self bar: theScale]; >> >> Now just removing one of two getter calls by caching its result won't >> have that much effect on binary size, but the other night I went >> through my code to do the exhaustively. The size decrease was quite >> significant. >> >> Using properties when a simple iVar would do is not justified. One >> wants to use properties only when the generated code significantly >> reduces the amount of work one has to do as a coder, for example by >> automagically taking care of retain counts. > > Once again you're using a bogus argument. There's nothing wrong (in most > cases) with using stack variables to "cache" property values or return values > as you have demonstrated. However, these are not ivars. > > Within a class implementation, there's often nothing wrong with reading ivars > directly. There's also nothing wrong with writing ivars directly, except that > there is generally memory management to consider (though, I guess, not when > you're using ARC). > >> Calling accessors is also quite slow compared to a direct iVar access, >> because it has to go through Objective-C's message dispatch mechanism. > > If you're talking about access from outside the class (that is, from clients > of the class), then the overwhelming consensus of developers who've being > using Obj-C for a while is that properties are a huge win, because they > provide useful encapsulation -- class implementation details, such as the > backing store (aka ivar) for a public property, are hidden within the class's > implementation. > > If you're talking about access within the class implementation, then the best > approach depends on the circumstances. In many cases, the self-discipline of > encapsulating property values yields greater robustness for subclasses, code > readability, etc. In many other cases, internal encapsulation is of no > benefit and direct ivar access is perfectly fine. > > I'll tell you, though, that (at least pre-ARC) the trend over the last > several years has been strongly in favor of using the properties, for > practical rather than theoretical reasons. Whether ARC might reverse this > trend isn't obvious yet. > >> Focussing on interface is no excuse for weighty, bloated code! > > I'm not sure what exactly this has to do with "interface". > > One mantra that gets repeated a lot on this list is 'No Premature > Optimization'. If the "weighty, bloated" accessors produce no significant > *measurable* effect on your app, there's no reason to avoid them. If there is > a measurable effect, and if the measurable benefits of optimizing your code > outweigh the development costs of doing so, then by all means the optimized > route is the way to go. > > > _______________________________________________ > > 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/conrad%40synthetiqsolutions.com > > This email sent to [email protected] _______________________________________________ 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]
