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.
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 generatedwrapper (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 thusBut 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@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel--- Sean Gillies http://zcologia.com _______________________________________________ geos-devel mailing list geos-devel@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ geos-devel mailing list geos-devel@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
