Garrett Rooney wrote:
> On 7/20/06, Nik Clayton <nik@ngo.org.uk> wrote:
>> Assuming I get the time to do the work, would anyone be interested in
>> patches to the Perl bindings to support named parameters as well as
>> positional parameters?
>>
>> This would mean that as well as being able to write code like:
>>
>> $ra->get_log([$paths], $rev, 1, 20, 0, 0, sub { ... });
>>
>> which is a bit obtuse (quick, without access to the docs, which of
>> those '0'
>> params is 'discover_changed_paths', and which is 'strict_node_history'?).
>> The changes I'm thinking of would let you write code like this:
>>
>> $ra->get_log({ paths => [ $paths ],
>> start => $rev,
>> end => 1,
>> limit => 20,
>> discover_changed_paths => 0,
>> strict_node_history => 0,
>> receiver => sub { ... } });
>>
>> Although it's more verbose, it's much more maintainable.
>>
>> Technically, this would involve any function that takes greater than 'n'
>> params looking to see if the first param is a hash ref, and unpacking the
>> parameters from the hash ref if so.
>>
>> I expect (but have not yet checked) that this could probably be
>> automated.
I would be delighted to be proved wrong, but I am very pessimistic about
the above (at least, not without integrating the functionality into the
core of SWIG itself - which would be a possible avenue, but would mean
that the enhancement couldn't be made available in Subversion until it
was released in SWIG and we had increased the minimum SWIG version to
the new release).
>> Any suggestions as to what an appropriate value for 'n' might be?
>> I suspect that '3' is a sensible minimum (i.e., any function that
>> takes 3 or more params should also support named parameters), but I
>> also think that if the work's going to happen then, for
>> consistency, all functions should be converted.
Personally, I'd set 'n' at zero, just for consistency's sake.
>> Just to stress -- this wouldn't remove the existing calling conventions.
>> Just add another option.
>>
>> Thoughts?
If it can be done in an automated way: sounds good!
If it cannot, as I fear: would introduce too much laborious-to-maintain
code to be worthwhile.
>> Also, having just spent 20 minutes chasing around the maze of files in
>> subversion/bindings, if anyone's got a "This is how SWIG is used with
>> Subversion" document, I'd appreciate a peek :-)
>
> I don't know if there's a simple document, but Max Bowsher has been
> looking at the swig stuff lately, so if you ask him nicely perhaps he
> could condense what he learned into something easily digestible...
A lot of it is experience rather than knowledget, but I guess as a
starting point:
*.i files are actual modules.
*.swg files are %included by *.i files and other *.swg files.
proxy/*.swg files are autogenerated.
include/*.swg files are manually written.
Support routines live in language specific libraries:
python/libsvn_swig_py
perl/libsvn_swig_perl
ruby/libsvn_swig_rb
There is a pure-Python/Perl/Ruby set of modules that wrap the ones
generated with SWIG, to provide a more natural interface and/or extra
helpers:
python/svn/
perl/native/*.pm
ruby/svn/
Max.
Received on Sat Jul 22 19:54:32 2006