Re: Deprecations

[Behdad Esfahbod <behdad cs toronto edu>]

On Thu, 27 Apr 2006, Owen Taylor wrote:

> On Thu, 2006-04-27 at 01:22 +0300, Mart Raudsepp wrote:
> > On Wed, 2006-04-26 at 21:23 +0100, Ross Burton wrote:
> > > On Wed, 2006-04-26 at 15:18 -0400, David Hampton wrote:
> > > > > Would it make sense to mark all of the deprecated API in GLib and GTK+
> > > > > with G_GNUC_DEPRECATED, so that people who are not using the
> > > > > DISABLE_DEPRECATED macros still get warned that they are using
> > > > > deprecated functions?
> >
> > Yes, pretty please.
> > I'm trying to nuke out all uses of deprecated functions, but declaring
> > all the *_DISABLE_DEPRECATED macros is a bit rough still (I can't test
> > on all of the combinations of systems the thing is supposed to not error
> > out)
>
> *_DISABLE_DEPRECATED is a tool for developers / for you; you should
> never ship like that, because *any* function may be deprecated in a
> future version and you have no control over that.
>
> Add a --configure switch that turns on *_DISABLE_DEPRECATED, configure
> your on compilations that way, fix all the resulting problems, but there
> is no benefit to shipping that way... a deprecation that one of your
> users sees but you don't is a deprecation you can't fix, because you
> aren't using a new enough version of GTK+ to have the replacement.

What we are doing in Pango and Gtk+ right now is to enable
G_DISABLE_DEPRECATED if and only if the major.minor version of
the available glib version is the same as the one we require.

I also like if there was a way to detect when the required
version of a module (glib and Gtk+ mainly) should be increased in
an application.  But that requires marking all the API with
macros and version number that I know is not going to happen...



> 						Owen

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"