Re: Why is GCompletion deprecated

On Mon, 2010-06-28 at 17:58 +0200, Salvatore De Paolis wrote:
> On Mon, 28 Jun 2010 14:49:48 +0100
> Emmanuele Bassi <ebassi gmail com> wrote:
> > the fact that nobody implemented them using GCompletion should give a
> > hint that: a) this is not a shared opinion and b) it probably wasn't
> > possible with GCompletion.
> That's not quite true, several applications use GCompletion, just to 
> mention some, Bluefish, Anjuta, Claws Mail.
> The issue isn't really about deprecating some code but instead not
> providing the alternative (look at QT for an idea, they always provided
> a compat library when it was necessary)
> This will be again the same picture as it has been with GTKCTree stuff:
> force application developers to waste time on changing something that
> actually just works and give room for new bugs while implementing the
> same functionality in a different way.

and, again, there is this false impression that deprecation is akin to

this code is *not* going away. it's been marked as deprecated because
nobody is actively maintaining it - and it hasn't been maintained for a
while, now. the deprecation merely states the obvious: this code is not
maintained and it should not be used in newly written applications
because no guarantees can be made on its state.

the code is not going to be removed until the next API bump - which, in
GLib's case, is neither planned nor (at this point) wanted.

you can either #undef G_DISABLE_DEPRECATED for the files that use these
particular data structures, or copy gcompletion.[ch] in your project;
since these files haven't been really changed in a while, the
maintenance burden for projects is not heavy.

> I think it's a good practice to always provide compatibility and i'd like
> if GTK+ would do that too.

the compatibility is all in the GLib API and ABI guarantees. since there
are no plans on bumping them, the deprecated code will still be



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]