On Fri, Jun 19, 2009 at 4:26 AM, Richard Frith-Macdonald <
rich...@tiptree.demon.co.uk> 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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
