Re: Why is GCompletion deprecated

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

   • 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

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.

Xavier Claessens.

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