It's not silly if it makes the SWIG bindings easier to maintain.
Agreed. Except the gdal bindings are harder to maintain in some ways due to the duplication of code.
Anyway, the difference in this case is that the GDAL object model is not as rich as in GEOS. GDAL just exposes "geometry" as opposed to point, line, etc.
I think this boils down to three major decisions about the SWIG bindings that need to be agreed on:
1. What geometry model do clients work with? Just geometry or geometry, point, line, etc.
2. What compatibility benefits does the C api provide beyond the benefits of the generated swig bindings?
3. How much of GEOS's api gets exposed to clients? For what its worth, my opinion is:1. Clients have to know about point, line, etc. even in the C-API because some methods are not valid for some geometries. So just show it to the clients, don't hide it. Plus, in object oriented languages like Python/Ruby it makes more sense.
2. I don't see any.3. This is an important one because you don't want clients using APIs that we know will change in the future. SWIG provides mechanisms to exclude classes and methods, but then you're somewhat duplicating the work the C API has already done to provide a limited API.
Charlie
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ geos-devel mailing list geos-devel@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
