[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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20060629/427c452f/smime.bin