[libvirt] [libvirt-glib] Correct namespace prefix for GVirConfig symbols

Zeeshan Ali (Khattak) zeeshanak at gnome.org
Thu Dec 22 18:21:24 UTC 2011


On Thu, Dec 22, 2011 at 7:55 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> On Thu, Dec 22, 2011 at 07:33:22PM +0200, Zeeshan Ali (Khattak) wrote:
>>   The patch improves the situation as it makes the whole API very
>> consistent w.r.t what exactly is the namespace here.
>
> Imo the namespace really is GVir::Config, not a GVirConfig namespace
> totally separate from the GVir namespace, so it does not make the whole API
> "very consistent", it just changes things.

  Even if the namespace is 'GVir::Config', my assertion that 'Config'
is part of the namespace and not just a symbol prefix is pretty much
correct so I don't understand what you are trying to discuss here.

>> I also
>> agree that nested namespaces will be better. If we decide/manage to go
>> towards nested namespaces, this patch actually helps in that regard as
>> well since existing API is not consistent/correct for that purpose
>> either.
>
> It helps *but breaks every library user*.

  Which user? Currently the API is hardly used by 2 apps. Keeping in
mind that library is still at its infancy and missing a lot of
essential API, this shouldn't be a concern at all since breaking
things now is preferable to breaking it later when apps really depend
on it and we promise some stability.

> Which is why you have to
> carefully weight the pros and cons. It makes things slightly nicer,
> slightly more consistent but *it breaks every user*. This is what makes it
> special and worth more considerations than a quick ack while everyone is on
> holidays.

  I disagree and think you sometimes worry way too much. :)

> Really, let's just wait until the holidays are over, as far as I'm
> concerned I wouldn't like having such a patch go in before I get a chance
> to see it even if I agree with it.

  Thats what I am going to do if there is no ACK for it anyway.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124




More information about the libvir-list mailing list