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
