On Fri, Feb 17, 2012 at 5:38 PM, Christophe Fergeau <cfergeau@redhat.com> wrote:
On Fri, Feb 17, 2012 at 05:25:30PM +0200, Zeeshan Ali (Khattak) wrote:
On Fri, Feb 17, 2012 at 5:18 PM, Christophe Fergeau <cfergeau@redhat.com> wrote:
On Fri, Feb 17, 2012 at 05:08:12PM +0200, Zeeshan Ali (Khattak) wrote:
(We already discussed at length why this is needed and we are already doing it for other boolean getters so lets not have the discussion about this need, again).
Actually this was discussed for libosinfo, not libvirt-glib, here is the relevant email for those who were wondering about this discussion:
https://www.redhat.com/archives/virt-tools-list/2011-November/msg00090.html
Ah ok but both libraries are meant to be first-class g* citizens and hence the same need to follow the usual conventions unless there is a compelling reason not to.
Making the C API as nice as possible to users is a very compelling reason to me since we are writing a C library (emphasis on the "to me", I know we disagree :)
Indeed we do. :)
This naming convention for getters is probably only useful for vala, I think bindings for dynamic languages will introspect object properties at runtime and use g_object_get().
Well, vala will also do the same but setting properties through that is known to be considerably slower than using the getter/setter directly (because of the type checks etc invovled in case of g_object_get).
So the decision to make is between making the API nicer to read for C users VS making life slightly easier for some bindings.
That is not the decision at all for me since I don't see anyone other than you complaining about the various gtk+ APIs following this convention. If you can cite examples of C developers complaining about it, that would be convincing argument to me. Otherwise, the decision to me is all about following a usual convention *that we already follow* and in turn make valac produce more efficient bindings vs making you happy.
Would a Rename to: annotation help vala here? Or is there some annotation I don't know of to mark property getters/setters?
Maybe? But I don't think we are that desperate yet. :) -- Regards, Zeeshan Ali (Khattak) FSF member#5124