On Tue, Jul 30, 2013, at 11:49 AM, Lee Ann Rucker wrote:
> 
> On Jul 30, 2013, at 8:48 AM, Andy Lee wrote:
> 
> > On Jul 30, 2013, at 11:25 AM, Scott Ribe <scott_r...@elevated-dev.com> 
> > wrote:
> >> On Jul 30, 2013, at 9:08 AM, Andy Lee <ag...@mac.com> wrote:
> >> 
> >>> I think it's subject to the same criticisms as *any* direct access to 
> >>> ivars, although I agree it feels sketchier when done in plain C for some 
> >>> reason.
> >> 
> >> Yes. Because what is the point of plain C functions in Objective-C files? 
> >> Local helpers that are not OOP, and do not go through method dispatch 
> >> overhead. To turn around and inject direct access to ivars in those is 
> >> really mixing metaphors.
> > 
> > One reason people might directly access ivars applies to methods as well as 
> > functions: the class may not have a getter method for that ivar.  Now, 
> > there is a school of thought that says ivars should *always* be accessed 
> > via a getter method, except in init and dealloc, and if necessary a 
> > "private" getter should be added.  If one does not subscribe to that school 
> > of thought, and accesses ivars directly in methods, I personally don't 
> > think it's a *huge* deal to do so in functions, especially since the 
> > function has to be inside the @implementation section and it won't be a 
> > commonplace thing.  But as always, I'm happy to code to the accepted norms 
> > of whatever team I'm on.
> 
> I'd go for [foo valueForKey:@"privateIvar"] over foo->privateIvar.

Why? It's morally equivalent, except it's slower, opaque to the
compiler, and reliant on the horrible default behavior of
+accessInstanceVariablesDirectly returning YES.

As far as I'm concerned, C functions that exist inside an
@implementation block are statically-dispatched instance methods.

--Kyle Sluder
_______________________________________________

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

Reply via email to