Hi Greg,
(I CC this to the svn mailing list too, so it's saves you the work of
reposting it. I hope this is ok.)
> Gerald,
>
> The note below is just one of many when I added a ctx field to one of the
> structures in SVN. I seem to recall suggesting to you that you could just
> bundle the structure into your own structure, but you had some reason that
> couldn't be done? Could you elaborate?
>
> In other words, why should there be a 'void *ctx' field rather than:
>
> struct my_hooks {
> dav_hooks_repository actual;
> void *my_data;
> };
>
My original request of this ctx field was for mod_dav, but the same
arguments applies to svn too. I run into problems while I was writing a Perl
API for mod_dav, so let me explain:
As long as I create the struct this wrapping should work, but in case the
struct is returned by mod_dav and I want to attach a Perl object that
doesn't work anymore.
For example in mod_dav the dav_get_resource function returns a dav_resource
structure. I need this structure in many other calls, for example to
retrieve properties. In Perl the dav_resource struct becomes an object. If I
have the ctx pointer I can store a reference to this Perl object in the ctx
member and anywhere I see this dav_resource struct (for example in some
callback, that is called from mod_dav into Perl) I can get my Perl object.
In this case I cannot use the a wrapper, because then I have to copy the
dav_resource struct, which may lead to invalid pointers in parts of the
other code.
I hope this make things more clear, if not just ask again. If I am overseen
something here and there is a better way to do these things I am happy to
learn...
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 2 08:41:25 2002