[Gdal-dev] Next Generation Language Binding News

[Kevin Ruland]

Hi all,

I thought I'd add a couple of things to what Howard had said.

>
> So, to recap where we're at, ng Python bindings are backward
> compatible (however lightly tested) with existing Python bindings, C#
> has bindings that are about 90% of the way there, and PHP bindings are
> on the horizon.  Now I'm going to explain what has yet to be done.
>

The Python bindings are supposed to be completely backwards compatible. 
On my machine they pass and fail the gdalautotest suite in exactly the
same way as the standard bindings.  It should be noted that the
gdalautotest suite is intended to test the gdal library functionality
and not the script bindings.  We were just lucky that they were written
in python and hence provided enough test cases to give us a reasonable
since of security.

Even though the gdal python bindings are backward compatible, I've heard
grumblings from other python users that they wanted to use python
exceptions to indicate problems rather than testing return codes.  So
the largest deviation from the standard bindings is the implementation
of optional exception generation.  By calling:

gdal.UseExceptions()

at the top of a script, all function calls which used to return status
codes not raise an exception.  This particular piece of functionality is
very experimental and I would like feedback on its correctness.  The
default behavour of the bindings is to return status codes, and you can
switch back by calling:

gdal.DontUseExceptions()

Please note, this has not been implemented in either osr or ogr yet.

The osr ng bindings are the most incomplete.  There are is a large
number of "Set*" methods in SpatialReference which are not wrapped at all. 

If anyone decides to work on another language binding, I would suggest
the following:

1)  Throw exceptions if they are natural in the script language.  Most
languages in common use today use exceptions within their standard
libraries.  The complexity to implement the "optional exceptions" is
rather unnatural and requires some wacky typemap tricks and additional
runtime overhead.  It was only done to maintain backward compatibility
with existing python scripts.

2)  There are methods which have multiple returns.  In Python and Php,
these return lists.  I don't know how to handle this in other languages
which are not so dynamic.  Also, I don't know exactly which functions do
return multiple values.

3)  The python bindings make heavy use of keyword args for optional
arguments.  In other languages these become positional arguments.  I
haven't tried to generate JNI bindings so I don't know what this ends up
looking like in Java or other languages which don't provide "vararg"
parameter calls.

Kevin