[Gdal-dev] Re: SWIG architecture

[Charlie Savage]

Hi Benjamin,

My understanding is that Frank made the decision to wrap using the C API 
and not the C++ API because the C API provides binary compatibility 
between releases.  In theory, this means that client applications are 
less likely to break when upgrading.

The same arguments have been put forth for the GEOS project, and in that 
case I've been migrating the SWIG bindings from the C++ api to the C API.

 From my viewpoint, I don't actually see how the C API provides better 
compatibility than the C++ api for the SWIG bindings (note it certainly 
does for C or C++ clients compiled against libgdal.so).  The reason I 
don't see any benefit is because for the languages I use (Ruby, but also 
Python) the host language is not relying on binary compatibility to load 
the SWIG built extensions (of course the extensions have to be 
recompiled for each new release but then again so does the C API). 
Instead, each language has hooks that you call to install new classes or 
methods.  Perhaps that is not the case for C# or Java, I haven't tried 
so I don't know.

The other argument for using the C API is that it limits what is exposed 
to clients, thus giving more freedom for the core of GDAL or GEOS to 
evolve over time without breaking clients.

Anyway, hope this helps.  I'm sure someone will chime in if I've missed 
some other reason.

Charlie







Anyway,
with the

http://geos.refractions.net/pipermail/geos-devel/2006-June/002317.html



binary compatibility

Collins, Benjamin wrote:
> To the SWIG folks,
> 
> We were interested in using more OGR features to handle vector formats
> from the SWIG'ed Java wrappers.  However, the currently exposed
> interfaces do not include the necessary functions to get information
> about polygons, etc; especially not in the natural way that such
> information is available in the C++ API.
> I thought I would see that would result from a more hands-off approach
> to the SWIG *.i files.  I created a new ogr.i file with the
> ogrsf_frmts.h file '%include'd along with some of the other main files.
> (Later I had to modify this a little, but not in any important way.)  I
> SWIG'ed this and got a full featured, more object oriented Java
> interface than before.  I am able to essentially use the C++ API with a
> straigt "transliteration."  Some language-specific typemaps could still
> help, but this is not the essence of the experiment.
> 
> So my question is this:  why does the SWIG wrapper wrap the C-stlye
> API.  Why not just go for the C++, get all the OO for free (esp w/
> OGRGeometry)?
> Also, why the use of *Shadow, etc?
> 
> I fully realize that there may be some caveat of SWIG keeping us from
> this approach.
> 
> Thanks,
> --
> Ben Collins