Giovanni Bajo wrote:
> On 10/04/2007 8.17, Sage La Torra wrote:
>
>>> Perl has Inline::C and Ruby has DL. I don't know if they are as good
>>> as ctypes. I saw this post on the users@ list:
>>> http://svn.haxx.se/users/archive-2005-06/0573.shtml
>>>
>>
>> You're right about Inline::C, among other cool Perl stuff. Perl has
>> some very good support for C in a variety of forms already, and as far
>> as I know this is being preserved in Perl 6. If you can make a C
>> binding, it can pretty much work in Perl, so don't worry too much
>> about that.
Inline::C is a little lower level (closer to C-level as it were) for
most Perl developers. In other words, the direct use of Inline::C would
be restricted to a few developers (where the Perl bindings developers
are still a very small number). It would mean that the Perl bindings
would be in a significantly worse place than they are now with SWIG
(which at least works for the pieces that are currently wrapped).
On a possibly related topic, I spent some time last week investigating
the doxygen XML output (as a way of programatically generating POD for
the Perl bindings). There /may/ be enough information in the C API as
exposed by the doxygen output to automatically generate Perl bindings,
but I don't know yet. It may be sufficient to use h2xs (which converts
C header files directly into XS code) as an initial pass, followed by a
"Perlification" of the interface (either manually or programatically
using the information encoded in the doxygen comments).
> Subversion already has a low-level API: the C API. Reinventing a
> still-low-level-but-not-identical C API with SWIG is not a good idea,
> but it would be a better idea if it were easier to achieve: and I mean
> easier for both SVN developers (maintaining the bindings), and binding
> users (which are let down by the complexities of building the SWIG
> bindings and SVN itself just to drive a commit by script... eg. for
> years we haven't had a Python 2.4 binding for Windows just because
> *nobody* was able to correctly compile it).
I agree that the C API would be the obvious target for the low level
bindings, with as little abstraction as required to make the bindings
"native" for the language involved (i.e. creating a native object that
would be the equivalent of the context pointer). But I'm leery of
having native higher-level abstraction API's for each language
individually. The more that the higher level API's diverge, the less
crossover development will be possible, which will again lead to the
less supported languages within the core developers getting less TLC...
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
Received on Tue Apr 10 15:39:39 2007