Greg Stein wrote:
> Create a special "setter" wrapper function for those members of the
> structure. Take a Python callable object, store that as the cancel baton,
> and put in a "thunk" for the cancel function.
I can already see the 'thunk' in swigutil_py.c
> As an example of the callable object -> func/baton, take a look at how the
> func/baton pairs are handled in svn_client.i.
Yes, I understand now. I have also identified the problem why it does
not work anymore:
SWIG is using a typemap mapping a python callback function to a function
pointer and the baton which is the callable. However, since we have it
in the client context now, this typemap never applies (because we use
the accessor functions).
> (the baton doesn't need to be exposed since the cancel function can simply
> be a bound method, meaning your "baton state" can be stored as instance
> variables in the bound object)
That's what I'm trying to do anyway. (see below)
> Last note: since we moved all of the notify/log/etc func/baton pairs into
> the client context, we might even be able to simplify svn_client.i since
> those data types won't appear as parameters. Would need to check. But
> whatever pattern is used to deal with the cancel func/baton structure
> members *would* definitely apply to the func/baton pairs in the client
> context structure.
I am not very fond of accessor functions anyhow. IMO they expose too
much detail of the C api to python (like the batons) and are wordy
because the function names are typically very long. Sometimes I felt
like I was writing C code with python syntax ;)
Since I already spent some time reading up on SWIG I'll take a look at
how to simplify the bindings from a python programmer's perspective, if
you guys don't mind. When I was reading SWIG docs yesterday, shadow
classes crossed my path. Would that be an option for wrapping all these
structs? Ideally, I would like to work only with objects in python code,
no low-level function calls.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 7 11:42:58 2003