Re: Perl swig bindings starting to smell

Nik Clayton wrote:
> I see you've committed 2646. Are you planning on closing the ticket too
> (I've not poked around tigris.org yet, so I need to find out how to do
> that).

I don't think us mortals have the appropriate rights to close tickets.
I was only planning on adding a comment to the bugtracker that it had
been applied on the branch and whoever actually merged it to trunk would
probably be able to also close the ticket.

> The patch in 2632 could use a little work. I'd remove the "I've not
> tested this" comments, and the examples should probably go in to a
> separate directory of example programs that use the bindings (or be used
> as test scripts).

As I said in my response to David's comments, I wanted to apply the
patch to the branch as is, then clean it up before asking it be merged
to trunk (revision history and all that).

> The major change that I've started is the one that introduces named
> parameters (and makes some of them optional if we can have sensible
> defaults for them).

And I'm perfect happy to review those changes, but don't expect much new
code from me (unless I get an itch I can't scratch while building the
tests). Initially, I'll focus on getting the two existing patches ready
to merge to trunk; I'll stay out of your way on the named parameters piece.

> This change would also introduce an external dependency on
> Params::Validate. I've bought this up before, and there didn't seem to
> be any objection to introducing this dependency, so I hope that will be
> fairly non contentious.

As long as the dependencies are fairly minimal, I think we can make the
argument that this is a reasonable tradeoff.

> A thought. Do we gain anything by instead switching to Module::Build?
> I have no idea, since I've not used it when building and binding against
> external libraries.

As much as I love Module::Build (most of my modules use it), it is not
core Perl (until v5.10.0), so it is harder to argue that M::B and the
dependencies needed to get it to build C code are minimal enough to come
under the previous paragraph above.

> * Make sure that, on a per-method basis, the bindings can find out which
> svn version a method was introduced (or otherwise be able to audit a
> piece of code and say "This requires svn 1.4.0 as a minimum version")

Perhaps we could extract that information from the Doxygen comments and
generate a module during the build that had that information. Have to
work out the appropriate API (which might involve changing the existing
bindings wrapper)...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org