On Wed, Jan 27, 2016 at 09:49:48AM +0100, Matthias Kuhn wrote: > Hi > > On 01/26/2016 10:32 PM, Nyall Dawson wrote: > > On 27 January 2016 at 03:31, Sandro Santilli <[email protected]> wrote: > >> On Tue, Jan 26, 2016 at 05:24:37PM +0100, Marco Hugentobler wrote: > >> That's a good news, thanks. > >> It would help to have a protocol defined to more easily tag > >> and identify which classes are and are not part of the API. > > By default anything that is LIB_EXPORTed should be considered stable > API.
git grep LIB_EXPORT does not give much interesting information. Are we talking about *_EXPORT macros ? I saw CORE_EXPORT and GUI_EXPORT. What else is there ? Any simple way to tell ? > There is already a tag which should catch most of the exceptions: > > @note not available in Python bindings This sounds easy to break. Aren't sip files automatically created ? > FWIW, the main goal should be that people writing code against the API > do not need to update their code with a minor version change. Makes sense. > Things available in Python should be treated extra-carefully. See above, how to tell if things are available in python ? > Anything not LIB_EXPORTed (or private) should be considered an > implementation detail, What about protected members ? > * Places like simplification that were explicitly implemented in WKB to > be able to work on the data before it's converted to an internal > structure for performance reasons. Is the above assuming every data provider would provide WKB ? I'd still think deserialized access would be faster... --strk; _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
