[geos-devel] Swig Update and questions

[Sean Gillies]

On Jun 24, 2006, at 6:02 PM, Charlie Savage wrote:

>> 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?
>

Charlie,

I'm doing something similar to your idea above. When a generic  
geometry is returned from a method, I check the GEOS type and then  
change the class of the result object to Point, LineString, etc.


> 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
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel

---
Sean Gillies
http://zcologia.com