On Tue, Jun 30, 2015 at 01:48:41PM +0100, Daniel P. Berrange wrote: > On Tue, Jun 30, 2015 at 02:38:24PM +0200, Christophe Fergeau wrote: > > On Tue, Jun 30, 2015 at 01:28:19PM +0100, Daniel P. Berrange wrote: > > > On Tue, Jun 30, 2015 at 01:25:28PM +0100, Zeeshan Ali (Khattak) wrote: > > > > On Tue, Jun 30, 2015 at 12:41 PM, Christophe Fergeau > > > > <cfergeau@xxxxxxxxxx> wrote: > > > > > Hey, > > > > > > > > > > Looks good to me, I'd name the type GVirNetworkDhcpLease rather than > > > > > GVirNetworkDHCPLease, this is consistent with > > > > > GVirConfigCapabilitiesCpuModel (and not CPUModel). > > > > > > > > Hm.. I was trying to keep it consistent with the underlying > > > > 'virNetworkDHCPLease'. > > > > > > I agree - IMHO acronyms should always be capitalized in our > > > APIs - use of Cpu is a bug (which we can't fix), but we should > > > not add more of such bugs. Likewise MAC, rather than Mac > > > > Fine with me then. Do you mean even in method names, or just in type > > names? > > Just types - for method names we use lowercase + underscores everywhere > which is fine as its in keeping with GLib common practice. We could have some typedef xxxCpuyyy xxxCPUyyy; if we want to 'fix' these wrong capitalizations. Christophe
Attachment:
pgp_1j7YNK9Gz.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list