On Fri, Jun 19, 2009 at 4:26 AM, Richard Frith-Macdonald
<address@hidden> wrote:
I would go further and ask what the point of the _private array is?
Well, the only reason I could come up with right now is that I didn't want to have to include GSSoundSink.h and GSSoundSource.h. The guy writing an application really doesn't care if these two protocols exist, so I figured it was best to hide the fact that I used them, and a NSCondtionLock, all together.
That's why I put this out there before continuing, I wanted to make sure it was a good decision.
By convention all the instance variables are private (that's what the leading underscore in the variable name means), so if all that's required is to inform developers that they should not use the ivars directly, there's no point in having the array, but maybe it would be worth using a @private declaration.
On the other hand, if the idea is to hide the implementation details so that ivar layouts won't need to change with future revisions (something I think we should all be doing), my preference would be to have a single pointer to a structure containing the required data.
eg.
struct _NSSoundInternal;
@interface NSSound : NSObject <NSCoding, NSCopying>
{
@private
struct _NSSoundInternal *_internal;
}
Then the designated initialiser allocates memory for the structure, clears it, and assigns the pointer when an instance is initialised, and -dealloc frees the memory at the end, and all internal references to ivars just go indirect from that pointer. The implementation is completely hidden/private and can be changed in subsequent releases without breaking the ABI.
Should I do this instead? Fact of the matter is, I'm not sure if the way I'm going about this is the best way forward, so chances are it'll eventually change (hence why I created an array of 4 (void *) but am only using 3 pointers). I would gladly go this route, specially since, like everyone else here, I'm all for ABI compatibility.
Thanks
Stefan