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