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/archive%40mail-archive.com This email sent to [email protected]
