Where do we put private ivars?

[MSch]

Which one do you prefer?

// declare ivars @private in .h
@interface NKAudioRecorder : NSObject {
@private
  CFURLRef                    fileURL_;
  AudioDeviceID               inputDeviceID_;
  UInt32                      audioChannels_;
  UInt32                      audioSamples_;
  AudioStreamBasicDescription fileFormat_;
  AudioStreamBasicDescription outputFormat_;
  AudioStreamBasicDescription deviceFormat_;
  ExtAudioFileRef             outputFile_;
  AudioUnit                   audioUnit_;
  AudioBufferList             *bufferList_;
}

// declare ivars as class extension in .m
@interface NKAudioRecorder () {
  CFURLRef                    fileURL_;
  AudioDeviceID               inputDeviceID_;
  UInt32                      audioChannels_;
  UInt32                      audioSamples_;
  AudioStreamBasicDescription fileFormat_;
  AudioStreamBasicDescription outputFormat_;
  AudioStreamBasicDescription deviceFormat_;
  ExtAudioFileRef             outputFile_;
  AudioUnit                   audioUnit_;
  AudioBufferList             *bufferList_;
}

[eaigner]

I would use with the @private form. Apple uses it in it's own headers and @private provides sufficient protection. An extra class extension would just add unnecessary overhead.

[myell0w]

Why declare ivars? properties in private class extension?

sent from phone

Am 06.07.2011 um 21:46 schrieb MSchreply@reply.github.com:

Which one do you prefer?

// declare ivars @private in .h
@interface NKAudioRecorder : NSObject {
@private
 CFURLRef                    fileURL_;
 AudioDeviceID               inputDeviceID_;
 UInt32                      audioChannels_;
 UInt32                      audioSamples_;
 AudioStreamBasicDescription fileFormat_;
 AudioStreamBasicDescription outputFormat_;
 AudioStreamBasicDescription deviceFormat_;
 ExtAudioFileRef             outputFile_;
 AudioUnit                   audioUnit_;
 AudioBufferList             *bufferList_;
}

// declare ivars as class extension in .m
@interface NKAudioRecorder () {
 CFURLRef                    fileURL_;
 AudioDeviceID               inputDeviceID_;
 UInt32                      audioChannels_;
 UInt32                      audioSamples_;
 AudioStreamBasicDescription fileFormat_;
 AudioStreamBasicDescription outputFormat_;
 AudioStreamBasicDescription deviceFormat_;
 ExtAudioFileRef             outputFile_;
 AudioUnit                   audioUnit_;
 AudioBufferList             *bufferList_;
}

Reply to this email directly or view it on GitHub: https://github.com/foundationkit/FoundationKit/issues/9

[MSch]

I personally prefer the class extension.

@myellow: using the ivar or self.ivar?

[eaigner]

@myell0w properties are overkill if you use them for EVERY ivar, especially for CF types.

[myell0w]

I'm for using the new runtime, not declaring any ivars and only synthesize properties. Direct ivar-access only in init, everywhere else dot-syntax

sent from phone

Am 06.07.2011 um 21:50 schrieb MSchreply@reply.github.com:

I personally prefer the class extension.

@myellow: using the ivar or self.ivar?

Reply to this email directly or view it on GitHub: https://github.com/foundationkit/FoundationKit/issues/9#issuecomment-1514666

[MSch]

@myell0w I like that approach (no ivars, only @properties), but is there a need to go for dot syntax when we are using ARC anyways? Or is there no performance difference?

[myell0w]

Overkill? no.

sent from phone

Am 06.07.2011 um 21:52 schrieb eaignerreply@reply.github.com:

@myell0w properties are overkill if you use them for EVERY ivar, especially for CF types.

Reply to this email directly or view it on GitHub: https://github.com/foundationkit/FoundationKit/issues/9#issuecomment-1514679

[eaigner]

Overkill? YES! At least in this case. You simply can't synthesize most CF types because they require a custom release. I'm not against synthesizing ivars where it makes sense, but you can't rule out EVERY manual ivar declaration because of that.

[myell0w]

in 99.9 % performance is no prob, setter/dot-syntax just ensures that KVO - stuff etc get's triggered, since memory is not important

sent from phone

Am 06.07.2011 um 22:02 schrieb MSchreply@reply.github.com:

@myell0w I like that approach (no ivars, only @properties), but is there a need to go for dot syntax when we are using ARC anyways? Or is there no performance difference?

Reply to this email directly or view it on GitHub: https://github.com/foundationkit/FoundationKit/issues/9#issuecomment-1514762

[eaigner]

I think there is a misunderstanding here. I refer to the code snippet above, not ivars in general. What I'm saying is:

• Synthesizing private properties for Cocoa objects: YES
• Properties for CF types: NO

[steipete]

No reason to get emotional about tech details -)

It's true that with CF types we don't can have the shiny new ARC things and still need ivars. I'm not entirely sure why CF types don't work well with properties, but i honestly never tried that - can you elaborate a bit more, Erik?

For ARC, my understanding is that we no longer need properties, as writing directly to ivars is preferred (as memory gets all sorted out automatically). And where assign was, we can directly add a __weak to the ivar. Using properties in ARC is a small performance overhead - but it's far from catastrophic. I may need some time to get used to it, as in the gefore-ARC timeline, I did it like Matthias, using ivars only in init/dealloc - helped a lot with memory bugs.

For general style, I usually put the ivars in the class. The "hide ivars with a private class extension" trick is pretty new, and I guess that apple's recent classes now use that too. Creating ivars in such categories wasn't possible in the old runtime. For header clean-ness, we can use that. Bu it's not an exclusive or. Sometimes you just want to hide some messy detail - that's where the .m extension is best for. For other vars that are expected, the header is "good enough".

[eaigner]

Because with CF types you can't always use CFRelease. CGPathRef for instance needs a CGPathRelease. It might not be a member of CoreFoundation, but it's still a CF class.

[myell0w]

Does using ivars directly also trigger KVO-events when using ARC? Don't think so and I think that's a pretty big issue. Also using setters/getters even in your own class ensures encapsulation.

[eaigner]

This thread is still about ivars, not properties exclusive.

[steipete]

With KVO, that probably... sucks. We have to wait until ARC finalizes to see what they come up with. It's just that in their videos (matthias, did u see them all? Esp not the basic ARC but the runtime advances in depth), they suggest to directly use ivars whenever possible.

With CF, Erik is probably correct, but it's (at least on iOS) a more exotic use case - still has to be considered, though.

[MSch]

So summing this up:

1. We need properties if we want KVO, properties overhead isn't significant. -> Use properties/synthesize/no-ivars for all objc objects.
2. CF needs ivars even with ARC -> use ivars for CF objects
3. Hiding ivars in class extensions: Just decide on a case by case basis, gut feeling, etc. -> General guideline: declare ivars in .h

This has my +1, what does everyone else think?

[myell0w]

• 1

sent from phone

Am 07.07.2011 um 21:08 schrieb MSchreply@reply.github.com:

So summing this up:

1. We need properties if we want KVO, properties overhead isn't significant. -> Use properties/synthesize/no-ivars for all objc objects.
2. CF needs ivars even with ARC -> use ivars for CF objects
3. Hiding ivars in class extensions: Just decide on a case by case basis, gut feeling, etc. -> General guideline: declare ivars in .h

This has my +1, what does everyone else think?

Reply to this email directly or view it on GitHub: https://github.com/foundationkit/FoundationKit/issues/9#issuecomment-1525298

[eaigner]

So I guess this is settled then. +1

[MSch]

Marking as needing final approval by @steipete

[steipete]

2., 3. is fine with me.

On that KVO-Properties or ivar thing: sometimes there are vars where it's pretty damn sure that noone ever wants to do KVO on it. In pre-ARC, i would all go for properties. But as ARC is so new, I don't want to make a final decision on that. Using properties is never a bad idea, so you can't go wrong with that. Just let's keep in mind that we should experiment a bit on that ivar issue.

tl;dr: properties, except with CF or when you think KVO is really useless here. ivar hiding -> when it get's too messy in .h