[geos-devel] Swig Update and questions

[strk at refractions.net]

On Sat, Jun 24, 2006 at 08:10:23PM -0600, Charlie Savage wrote:
> Thanks for the info Sean.
> 
> If the swig bindings used the C api and did the same check for the geom 
> type, would there be any difference between them and the Python 
> bindings?  Are they any specific python features you added to them to 
> make them easier to use from Python?  Anything that couldn't be done in 
> SWIG?  Just wondering if we can combine efforts here.

I'd highly appreciate a combined effort on the binding.
I think the best would be SWIG/CAPI, bearing with SWIG version
found on debian stable.

--strk;

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



> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel


-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.