On Saturday, February 1, 2003, at 04:02 PM, Greg Hudson wrote:
> On Sat, 2003-02-01 at 14:11, rooneg@tigris.org wrote:
>> ok, i admit it, gstein was right. making the context object opaque
>> was
>> premature, and if it turns out we need to do so (for caching config
>> options
>> or something), we can always make part of it private (concealed
>> behind a
>> void pointer) later on.
>>
>> * subversion/include/svn_client.h
>> (svn_client_ctx_t): make the definition of this struct public
>> information,
>
> If I understood the conversation right, Greg was arguing that the
> context object should still be opaque to users of svn_client, just not
> to the internals.
this is quite possible, and would be a nice compromise, as the setter
functions are perfectly reasonable outside of libsvn_client, it's just
inside where it becomes exceedingly annoying to have to use the getters
all the time.
> Also, opaqueness does not demand a null pointer. All you need is a
> forward struct declaration ("struct foo;" or "typedef struct foo bar;"
> as appropriate) in the public header file.
oh, i'm aware of that, i'm just thinking of something like what philip
had proposed in one of his mails on the subject, some kind of hybrid
where the struct looks like this:
typedef struct context {
svn_foo_funcptr_t funcptr;
void *foo_baton;
/* other callback/baton pairs go here */
void *context_baton;
} context_t;
and we allow the client (and libsvn_client for that matter) easy access
to the vtable part, where all it's doing is setting things, and use the
context_baton member variable to conceal parts that should be private
to libsvn_client (caching of things that the client app shouldn't mess
with, for example).
honestly, i think i like the idea of moving the structure definition
into libsvn_client/client.h and having it be opaque (with setter
functions) for users of libsvn_client, but i'm going to leave things as
they are for a few days and let people chime in on it, since having the
interface as it is doesn't really hurt us much for now.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 2 06:21:32 2003