I have no objection. I know Vicky was complaining about the large number of functions that should be private that are exposed. She was planning to deprecate them in 3.8 and remove/make private in a later release.
I'm not sure if this is related to that if she's even looked at that class. Are these linked into CAPI at all? If so we should probably stub them with an error, if not, I don't care if they are removed as we never said the C++ -API is stable yet. My hope is once we clean things up a bit, we can guarantee some level of stability for the C++ API as well. Thanks, Regina From: geos-devel [mailto:[email protected]] On Behalf Of Daniel Baston Sent: Thursday, August 30, 2018 9:10 AM To: GEOS Development List <[email protected]> Subject: [geos-devel] Refactoring CoordinateSequence I've been exploring porting the PackedCoordinateSequence from JTS to GEOS because it seems like a useful way to improve the interoperability of GEOS with other code (LWGEOM, for example) without requiring copying of everything into GEOS data structures. It turns out that extending CoordinateSequence is pretty onerous in GEOS; the CoordinateSequence class contains many abstract methods that are not in the corresponding CoordinateSequence JTS interface. These methods add requirements of mutability (CoordinateSequence::setAt) and extensibility/contractability (CoordianteSequence::add, CoordianteSequence::deleteAt) and require the author of a derived class to implement functionality that could be seen as unrelated to storing a sequence of coordinates (removeRepeatedPoints, apply_ro, etc.). Does anyone know why so many methods are added to GEOS CoordinateSequence that have no JTS equivalent, and are there any objections to factoring some of the functionality out of the CoordianteSequence class so that it's easier to write other CoordinateSequence implementations? Dan
_______________________________________________ geos-devel mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/geos-devel
