• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mixing Obj-C and C "methods"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mixing Obj-C and C "methods"


  • Subject: Re: Mixing Obj-C and C "methods"
  • From: Kyle Sluder <email@hidden>
  • Date: Tue, 30 Jul 2013 12:10:14 -0700

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 <email@hidden> wrote:
> >> On Jul 30, 2013, at 9:08 AM, Andy Lee <email@hidden> 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 (email@hidden)

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:

This email sent to email@hidden


References: 
 >Mixing Obj-C and C "methods" (From: Vincent Habchi <email@hidden>)
 >Re: Mixing Obj-C and C "methods" (From: Rick Mann <email@hidden>)
 >Re: Mixing Obj-C and C "methods" (From: Andy Lee <email@hidden>)
 >Re: Mixing Obj-C and C "methods" (From: Scott Ribe <email@hidden>)
 >Re: Mixing Obj-C and C "methods" (From: Andy Lee <email@hidden>)
 >Re: Mixing Obj-C and C "methods" (From: Scott Ribe <email@hidden>)
 >Re: Mixing Obj-C and C "methods" (From: Andy Lee <email@hidden>)
 >Re: Mixing Obj-C and C "methods" (From: Lee Ann Rucker <email@hidden>)

  • Prev by Date: Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work
  • Next by Date: NSTrackingRect not always working
  • Previous by thread: Re: Mixing Obj-C and C "methods"
  • Next by thread: Re: Mixing Obj-C and C "methods"
  • Index(es):
    • Date
    • Thread