[geos-devel] Swig Update and questions

[Charlie Savage]

> We surely want them distributed. We also want to distribute the generated
> wrapper (for those not having unstable swig installed).
> Would be nice if make maintainer-clean would get rid of the latter
> and next make would recreate it.
> (haven't tested your new makefiles yet)

Okay, so I need to add in a hook for make maintainer-clean then and to 
have make check to see if the generated wrapper exists or not and create 
if needed (I think the makefiles already do that actually).

Anything I need to do for getting the files into the distribution?

Haven't checked in my changes yet, I want to first test them some more.

> 
>> * Who owns the geometries returned from methods such as Intersection, 
>> Difference, etc?  The C API doesn't give any indication and it wasn't 
>> obvious to me looking through the C++ code.
> 
> A rule of thumb for the C API is:
> Every Geometry caller should take care of is returned
> as a non-const object.
> For these specific case the caller must delete them.

Okay, so the caller needs to delete the results of methods like 
Intersection.  Assumedly the same goes for using the C++ api - i.e, 
geom->intersects(someOtherGeom)?


While on the subject, I've taken a look at what would be involved with 
having the SWIG wrappers use the C api.  Its doable - basically I would 
have SWIG create "fake classes" which look like classes to Ruby/Python 
but underneath use the C API.  This is how the GDAL swig bindings are 
implemented, so its ok.  It is a bit silly (duplicate definitions), but 
it works.

But the thing that holds me back is that in the c-api all the geometry 
types get merged into just Geometry (no points, linestrings, etc.). 
That might be ok for C, but me would seem very strange in Ruby or 
Python.  I've thought its too high too high a price to pay and thus

But I wonder if there is a way around this by using a variation of the 
PIMPL idiom (http://www.gotw.ca/publications/mill05.htm)?

Something like forward declare all the Geos geometry classes, but of 
course don't call any methods on them.  Then for any C-API method that 
returns a geometry do a dynamic_cast to see what it is and then return 
an appropriate SWIG wrapper classes.

Sean or Hobu - didn't one of you write your own bindings for Python not 
using SWIG?  How did you handle this?  Are you happy with just having a 
Geometry object and you have to make sure to use it correctly (if its a 
point don't call NumRings)?  Or did you do something more clever?

In the end though I wonder if there is any real benefit to using the C 
api for the swig bindings. The c-api is supposed to insulate a program 
from changes to the underlying C++ api.  But the bindings libraries 
already do that.  Python/Ruby will dynamically load the bindings and 
install the appropriate classes/methods.

That means can install a new version of GEOS, swap out the bindings 
library, restart your program, and all should be well as long as you 
haven't removed any methods (it doesn't matter if methods or classes or 
changed namespaces or changed hearder files or whatever).  Now if you 
swapped out the version of GEOS and not the bindings, then you'd run 
into problems (but you would also with the C-API).

There is also the point that everything is statically linked on Windows 
  (since geos doesn't export any functions), so it doesn't matter at all 
if the version of geos is changed on the machine.  You could do the same 
on Linux/Unix I suppose.

Well, after all that rambling I've talked myself back into the idea that 
the SWIG bindings should stick with the C++ api because the C api 
provides no forward compatibility benefit (it does provide benefit, or 
disadvantage depending on your viewpoint, of a much smaller API).  But 
I'm more than happy to listen to counter arguments and do the work to 
switch over to the C api if its demonstrably better.

Charlie
-------------- 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/geos-devel/attachments/20060624/ce485bbb/smime.bin