From kde-optimize Wed Feb 05 12:00:08 2003 From: Jaime Torres Date: Wed, 05 Feb 2003 12:00:08 +0000 To: kde-optimize Subject: RE: avoid deprecated methods X-MARC-Message: https://marc.info/?l=kde-optimize&m=104444642701212 MIME-Version: 1 Content-Type: multipart/mixed; boundary="------_=_NextPart_001_01C2CD0E.211DEA00" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2CD0E.211DEA00 Content-Type: text/plain; charset="iso-8859-1" > 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 > ------_=_NextPart_001_01C2CD0E.211DEA00 Content-Type: text/html; charset="iso-8859-1" RE: avoid deprecated methods

> 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
>

------_=_NextPart_001_01C2CD0E.211DEA00-- _______________________________________________ Kde-optimize mailing list Kde-optimize@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-optimize