[Qgis-developer] Can I change QgsAbstractGeometryV2::fromWkb signature ?

[Sandro Santilli]

Another thing to consider is whether the API methods should
be ensured to be found in the library (vs. just implemented
as inlined proxies).
In other words, do we also need to retain ABI ?

--strk;

On Tue, Jan 26, 2016 at 05:12:24PM +0100, Sandro Santilli wrote:
> On Tue, Jan 26, 2016 at 04:53:20PM +0100, Matthias Kuhn wrote:
> > 
> > 
> > On 01/26/2016 04:45 PM, Sandro Santilli wrote:
> > > On Tue, Jan 26, 2016 at 01:52:41PM +0100, Matthias Kuhn wrote:
> > >> I would add a second method with size param and deprecate the current one.
> > >> This way we can prepare our own code and remove the dangerous method in 3.0
> > > Consider that QgsGeometry::fromWkb() already takes a size parameter:
> > >
> > > https://github.com/qgis/QGIS/blob/master/src/core/geometry/qgsgeometry.h#L141-L145
> > >
> > > It's just not passed over to the QgsAbstractGeometryV2::fromWkb.
> > > Is the "internal" call still to be considered part of the API ?
> > 
> > Why not?
> > Is there a problem with the proposed approach? I would say it is quite
> > safe and future proof.
> 
> Well, I wouldn't call it "safe".
> It is a way to still allow "unsafe" code to run.
> 
> It's not even "cheap" as a measure: if every single method has to be
> considered part of the API, it'd take a lot of code duplication to keep
> the deprecated version alive.
> 
> QgsAbstractGeometryV2::fromWkb is re-implemented for each and every
> subclass. Each subclass ends up calling WkbPtr which is currently also
> not bound-checking, so we'd need another method duplication there.
> 
> Each of the deprecated methods would need to call the safe version
> with an arbitrarily choosen "length" (max int, I guess?).
> 
> Is there a way to tell what's part of API and what's not ?
> 
> 
> --strk;