'RE: avoid deprecated methods'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-optimize
Subject: RE: avoid deprecated methods
From: Jaime Torres <jtorres () sia ! es>
Date: 2003-02-05 12:00:08
[Download RAW message or body]

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

[Attachment #3 (text/html)]

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

_______________________________________________
Kde-optimize mailing list
Kde-optimize@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-optimize

[prev in list] [next in list] [prev in thread] [next in thread] 