avoid deprecated methods

Wed, 5 Feb 2003 13:00:08 +0100

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"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: avoid deprecated methods</TITLE>
</HEAD>
<BODY>

&gt; On Tuesday 04 of February 2003 18:00, Alexander Neundorf wrote:
 &gt; &gt; On Tuesday 04 February 2003 11:24, Stefan Heimers wrote:
 &gt; &gt; &gt; This is a good point. I would recommend moving deprecated 
 &gt; methods out of
 &gt; &gt; &gt; qt/kdelibs into a separate libraby.
 &gt; &gt;
 &gt; &gt; That's not possible, these methods are usually member 
 &gt; methods which belong
 &gt; &gt; to their class.
 &gt; &gt;
 &gt; &gt; But the #ifdef would be a good thing.
 &gt; 
 &gt;&nbsp; It should be possible, you can simply omit implementation of 
 &gt; some methods, 
 &gt; and as long as they're not referenced, it will be fine. Even 
 &gt; the #ifdef is 
 &gt; there, it's called KDE_NO_COMPAT (and QT_NO_COMPAT), so you 
 &gt; can just add 
 &gt; &quot;-DKDE_NO_COMPAT -DQT_NO_COMPAT&quot; to your compile flags and try.
 &gt; 
 &gt;&nbsp; On the other hand, I don't think there should be any 
 &gt; official support for it, 
 &gt; as that would be likely to break anything but a carefully 
 &gt; handled install 
 &gt; from sources, where the person wouldn't care about things 
 &gt; like no backwards 
 &gt; 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.
 &nbsp;
 &gt;&nbsp; 300KiB of shared memory isn't that much, given the libs take 
 &gt; roughly 15MiB in 
 &gt; total. Moreover I think it would be less, most NO_COMPAT 
 &gt; methods are simple 
 &gt; wrappers, so they would be less than 1KiB each.

<P><FONT SIZE=2>I was not talking about NO_COMPAT methods but methods that are documented</FONT>
<BR><FONT SIZE=2>in their documentation header as @deprecated.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>&gt; -- </FONT>
<BR><FONT SIZE=2>&gt; Lubos Lunak</FONT>
<BR><FONT SIZE=2>&gt; KDE developer</FONT>
<BR><FONT SIZE=2>&gt; ---------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; SuSE CR, s.r.o.&nbsp; e-mail: l.lunak@suse.cz , l.lunak@kde.org</FONT>
<BR><FONT SIZE=2>&gt; Drahobejlova 27&nbsp; tel: +420 2 9654 2373</FONT>
<BR><FONT SIZE=2>&gt; 190 00 Praha 9&nbsp;&nbsp; fax: +420 2 9654 2374</FONT>
<BR><FONT SIZE=2>&gt; Czech Republic&nbsp;&nbsp; <A HREF="http://www.suse.cz/" TARGET="_blank">http://www.suse.cz/</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; Kde-optimize mailing list</FONT>
<BR><FONT SIZE=2>&gt; Kde-optimize@mail.kde.org</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="http://mail.kde.org/mailman/listinfo/kde-optimize" TARGET="_blank">http://mail.kde.org/mailman/listinfo/kde-optimize</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2CD0E.211DEA00--