Deprecation Defines

[David Faure]

On Wednesday 09 July 2014 22:01:06 Alex Merry wrote:
> On Tuesday 08 July 2014 14:03:31 Matthew Dawson wrote:
> > On July 8, 2014 10:50:18 PM David Faure wrote:
> > > But yeah, the Qt solution with version-specific deprecation
> > > (QT_DEPRECATED_SINCE) is much better, we should adopt something like
> > > that.
> > > This way, you can ensure your code keeps compiling "without the stuff
> > > that
> > > was deprecated in 5.1", without getting a compilation error if someone
> > > suddenly installs KF 5.2 which deprecated new stuff. This means not
> > > using
> > > the stuff currently in cmake then, but something more evolved based on
> > > the
> > > project's version number...
> > 
> > QT_DEPRECATED_SINCE would erase my complaint, as the new deprecations
> > won't
> > disappear on the application.
> 
> I like this DEPRECATED_SINCE idea. We could have two versions of the
> wrapping macro, one for stuff that's BC to hide (ie: no virtuals or class
> data members), and one for stuff that's BIC. The former could be controlled
> by an application- set macro, while the latter would be controlled by the
> framework's build options.

I'm not sure we want BIC stuff in there, it just seems too dangerous (apps 
would break if they reimplement deprecated virtual methods, which would then 
no longer be called) and complex (we'd have to think of what happens with and 
without the define, etc.).
Qt doesn't do that, it simply adds TODOs for Qt 6.

But yeah, a Qt-like DEPRECATED_SINCE would be really useful.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5