You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2003/02/01 21:02:38 UTC

Re: svn commit: propchange - rev 4700 svn:log

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.

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: propchange - rev 4700 svn:log

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
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