[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Why is GCompletion deprecated
From:       Xavier Claessens <xclaesse () gmail ! com>
Date:       2010-06-28 19:41:03
Message-ID: 4C28FACF.4010409 () gmail ! com
[Download RAW message or body]

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.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[prev in list] [next in list] [prev in thread] [next in thread]