[libvirt] [libvirt-glib] Add gvir_domain_get_saved()

Christophe Fergeau cfergeau at redhat.com
Fri Feb 17 16:53:40 UTC 2012


On Fri, Feb 17, 2012 at 06:31:31PM +0200, Zeeshan Ali (Khattak) wrote:
> > This is such a small annoyance that noone will complain only about it,
> 
> Small? And yet we keep discussing this all over again and again in
> detail?

You skipped the rationale as why I think it's small but can be important.
And this is the first time we have this discussion for libvirt-glib. My
initial concern was that "get_saved" looks weird btw, not that we have to
use "is_saved".


> By following a usual convention that we are already following and
> something we have already discussed and we already went with my
> proposal.

In libosinfo.

> If you would be making me go through this each time we add a
> boolean getter, please go ahead and change the API that way you think
> is pretty. I won't object at all, as long as you change all the other
> getters too in both libosinfo and libvirt-glib.


The initial concern was with the naming of the _get_saved function where I
indicated my personal preference for an API as good as possible, then this
became "shut up, everyone is using _get_saved so it's the only thing that
should be considered, this is not even worth mentioning anything else!!".

Even the initial name was quite easy to explain given that we want it to be
similar to gvir_domain_save, and we want to use _get_ for getters. Which
would have been 1) constructive 2) enough to get me to think again about
the naming.

> Alternatively we can both compromise and agree on 'get_is_saved'.

Both would probably work, not sure which one is less bad. By the way, gtk+
doesn't use _get_ when there is no associated g_object_property (especially
with _has_), we really should start adding actual properties and not only
getters :)

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120217/daa5ed97/attachment-0001.sig>


More information about the libvir-list mailing list