Re: Why is GCompletion deprecated

[Xavier Claessens <xclaesse gmail com>]

Le 28/06/10 18:46, Emmanuele Bassi a écrit :
> 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.

Great, this is what I was asking for. I didn't know about this :-)

If those are the only issues, looks pretty trivial to deprecated 
GCompletion, and create a new API that don't have those issues. Maybe if 
there were a public call for help to fix those issues, we could have a 
replacement by now. Or did I missed an email where this was explained?

If you think about other issues, please don't forget to tell us.

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

I totally agree. I'm not against deprecating GCompletion, just needed to 
know what is needed to bring back that feature in GLib ;-)

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

Didn't meant to be rude, sorry. I explained in another email what I meant.

Regards,
Xavier Claessens.