At the risk of overstepping...this is open-source software. You never prevent anyone from using any bits that they like. All you're doing by annotating or otherwise hiding things is saying that such code may not exist in future releases, which may or may not be important for users. People who are going to use "private" bits are almost by definition taking some responsibility for integration and upgrades if they desire them.
On Wed, Dec 7, 2022 at 10:05 AM Daniel Baston <dbas...@gmail.com> wrote: > Do you build a shared library? If so, limit what you export to what you >> want to be your API. Don't document anything else. >> >> Maybe I'm missing something in what you're asking. >> > > I don't think you're missing anything, and these are routes we could take. > I am inclined to look for a solution that flags "stable" methods but > doesn't actually prevent the user from using methods not flagged as such. > For example, we could flag all non-stable methods in such a way that a > compiler warning is generated unless the user has defined > "USE_NON_STABLE_API" or whatever it's called. But since the unstable > methods will greatly outnumber the stable ones, it would be nice to have > something that didn't require us to put an extra directive all over the > place. > > Dan > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel > -- Andrew Bell andrew.bell...@gmail.com
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
