Re: Why is GCompletion deprecated

[Emmanuele Bassi <ebassi gmail com>]

On Mon, 2010-06-28 at 16:24 +0100, Martyn Russell wrote:
> On Mon, 2010-06-28 at 14:49 +0100, Emmanuele Bassi wrote:
> > On Mon, 2010-06-28 at 15:26 +0200, Xavier Claessens wrote:
> > 
> > > 1) I can think a bazillion of UIs that do/should have completion.
> > 
> > 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.
> 
> You know this categorically?
> 
> Under my own submission, the GtkEntryCompletion does cover most things I
> ever needed. But I was quite surprised to read Xavier's email this
> morning. I would have thought this was quite useful/used.

Google code search returns a few legitimate users (as soon as you
discount the apps copying glib in their own sources), many of which are
old versions of existing applications.

> > >  Maybe 
> > > they can do that completion with something else than GCompletion, but 
> > > then the deprecation warning in the gtk-doc should point to that other 
> > > API. Probably GtkEntryCompletion is useful here, but can it be used with 
> > > editable GtkTextView (what empathy uses to write IM)?
> > 
> > please, come up with a better API; since I very much doubt you can fix
> > GCompletion to actually be useful for everyone, it would still require a
> > deprecation of the GCompletion API.
> 
> I am curious as to what the reasoning was here?

a 2 minutes API review of GCompletion:	

  • g_completion_new(): not bindable; requires at least a new version
with a GDestroyNotify function for language bindings.

  • the GCompletionFunc doesn't have a data parameter, making it
unbindable.

  • the GCompletion structure is completely exposed and cannot be
extended or updated, hence we cannot add a GCompletionFuncData that
takes a user data parameter, unless we use the struct alignment C trick,
in which case the func pointers will be set to NULL even in valid cases.

  • the same applies for GCompletionStrncmpFunc.

  • the whole API uses untyped lists, which makes its use awkward from
anything that's not C - and even in C it's odd to use, especially with
regards to bookkeeping of the items.

and this is just the API review - I didn't touch the implementation.

honestly, I think this API was added too early in the GLib development
cycle, without many users or a clear scope.

the same could be said of GRelation, which has even fewer users.

> Also, it is hardly in the open community spirit to tell people to "come
> up with a better API" and then follow that with doubt that it will be
> useful.

that's not what I wrote. I wrote:

| since I very much doubt you can fix GCompletion to actually be useful
| for everyone, it would still require a deprecation of the GCompletion
| API.

I expressed doubts that you can effectively change GCompletion in an
ABI/API compatible way; I honestly don't think it's possible without
breaking some existing code.

you can definitely write a new GCompletion API - and I very much
encourage you to do so, if you wish, and propose it for inclusion after
different applications used it. this would lead in any case to a
deprecation of GCompletion as it is.

> > > Surely good reasons where discussed with the community before 
> > > deprecating the API, but I didn't find public discussion. If I missed 
> > > it, please just give me the link ;-)
> > 
> > I seem to have lost the memo requiring public discussion with the
> > community for a maintainership decision. probably my bad. can you point
> > me to it?
> 
> Again, I think this is quite uncalled for.

really? after:

| 2) If all unmaintained code should be deprecated with no replacement, 
| what do we have left in glib/gtk? Probably not that much...

I say it was perfectly called for.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi