>> The reason I grimmace is that I've seen countless problems with bindings, KVC, and memory management where people blame the frameworks
Uhh, yes - the frameworks should be presumed innocent until conclusively proven guilty: ten bazzillion other folks are using these things without much of a hiccup, so the odds are it's your oddball code, not the frameworks...
Um.. for the benefit of the other readers (as we - Scott and I - have been over it already :-) it is my general position that true private ivars should never be used with KVC/KVO or bindings; as those mechanisms all are open to the outside world, so anything used with them should be at least in the protected scope, if not public. And if it's at least protected, then: a) it most definitely should have accessors, b) it should not have prepended underscores (Apple's names or not), and c) it should be well documented so the rest of us can avoid hitting it.
Although Apple says not to do it (and so I don't do it in my code), I don't think it's actually harmful to prepend an underscore on a @private declared ivar, because the compiler will catch ivar namespace collisions and throw an error.
As for the memory management; yup, it's a hazard that must be watched out for. Whenever I get a "bad access" crash, the first thing I think is either I forgot to nil something out or I released something that I shouldn't have -- tracing the origin of the bad pointer back thru the code will usually turn up the culprit.
>> Just to be clear, I don't think the XY_ syntax is actually a recommendation, as much as it is a suggestion.
Yes - you're right; that's certainly not the only way to get around the issue, nor does Apple say "thou shalt".
>> The only real recommendation is avoid single and double-underscores at the beginning of a method name.
Well, Apple does actually call it out for ivars, too, but because the compiler throws errors in that case, I don't think it's as big an issue as with method names (which can cause silent failures, sometimes in already shipped code if the frameworks change out from under you with a system update).
by britt — Nov 04
Uhh, yes - the frameworks should be presumed innocent until conclusively proven guilty: ten bazzillion other folks are using these things without much of a hiccup, so the odds are it's your oddball code, not the frameworks...
Um.. for the benefit of the other readers (as we - Scott and I - have been over it already :-) it is my general position that true private ivars should never be used with KVC/KVO or bindings; as those mechanisms all are open to the outside world, so anything used with them should be at least in the protected scope, if not public. And if it's at least protected, then: a) it most definitely should have accessors, b) it should not have prepended underscores (Apple's names or not), and c) it should be well documented so the rest of us can avoid hitting it.
Although Apple says not to do it (and so I don't do it in my code), I don't think it's actually harmful to prepend an underscore on a @private declared ivar, because the compiler will catch ivar namespace collisions and throw an error.
As for the memory management; yup, it's a hazard that must be watched out for. Whenever I get a "bad access" crash, the first thing I think is either I forgot to nil something out or I released something that I shouldn't have -- tracing the origin of the bad pointer back thru the code will usually turn up the culprit.
>> Just to be clear, I don't think the XY_ syntax is actually a recommendation, as much as it is a suggestion.
Yes - you're right; that's certainly not the only way to get around the issue, nor does Apple say "thou shalt".
>> The only real recommendation is avoid single and double-underscores at the beginning of a method name.
Well, Apple does actually call it out for ivars, too, but because the compiler throws errors in that case, I don't think it's as big an issue as with method names (which can cause silent failures, sometimes in already shipped code if the frameworks change out from under you with a system update).
:-)