avoid deprecated methods

[Benjamin Meyer]

No matter what we do do it would be a good idea to have a common way of 
specifing things that are deprecated so when we do break binary compatibility 
(down the line) we will have a nice big list of old deprecated functions to 
prune.  Is "@deprecated" in the header the correct way of doing this?

-Benjamin Meyer

On Wednesday 05 February 2003 7:00 am, Jaime Torres wrote:
> > On Tuesday 04 of February 2003 18:00, Alexander Neundorf wrote:
> > > On Tuesday 04 February 2003 11:24, Stefan Heimers wrote:
> > > > This is a good point. I would recommend moving deprecated
> >
> > methods out of
> >
> > > > qt/kdelibs into a separate libraby.
> > >
> > > That's not possible, these methods are usually member
> >
> > methods which belong
> >
> > > to their class.
> > >
> > > But the #ifdef would be a good thing.
> >
> >  It should be possible, you can simply omit implementation of
> > some methods,
> > and as long as they're not referenced, it will be fine. Even
> > the #ifdef is
> > there, it's called KDE_NO_COMPAT (and QT_NO_COMPAT), so you
> > can just add
> > "-DKDE_NO_COMPAT -DQT_NO_COMPAT" to your compile flags and try.
> >
> >  On the other hand, I don't think there should be any
> > official support for it,
> > as that would be likely to break anything but a carefully
> > handled install
> > from sources, where the person wouldn't care about things
> > like no backwards
> > compatibility, possibly broken binary compatibility, and so on.
>
> The main advantage here is not to use these methods in future releases.
> In that way you can compile it with those flags and see if some of the
> deprecated methods are used, that I am pretty sure (not checked yet)
> that they are used in the 3.1.
>
> >  300KiB of shared memory isn't that much, given the libs take
> > roughly 15MiB in
> > total. Moreover I think it would be less, most NO_COMPAT
> > methods are simple
> > wrappers, so they would be less than 1KiB each.
>
> I was not talking about NO_COMPAT methods but methods that are documented
> in their documentation header as @deprecated.
>
> > --
> > Lubos Lunak
> > KDE developer
> > ---------------------------------------------------------------------
> > SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
> > Drahobejlova 27  tel: +420 2 9654 2373
> > 190 00 Praha 9   fax: +420 2 9654 2374
> > Czech Republic   http://www.suse.cz/
> >
> > _______________________________________________
> > Kde-optimize mailing list
> > Kde-optimize@mail.kde.org
> > http://mail.kde.org/mailman/listinfo/kde-optimize