Re: [libvirt] [PATCH v4 00/17] virObject adjustments for common object

On Fri, Aug 18, 2017 at 17:50:24 -0400, John Ferlan wrote: [...] Yes. I'm here to complain about this. As I've pointed out some time ago, abstracting stuff, which you can't name properly does not seem to make sense if you are in the end attaching it to something non-generic. This makes such helpers hard to use and hard to remember which fields serves which purpose in the given use case. This also then triggers custom wrappers for every single usage area where you put names to those fields. Could you elaborate please on the purpose and final goal of this. I was't able to piece together what you are trying to achieve. If you want to unify the code that sections of libvirt use to hold lists of objects I don't think you need a custom sub-type for them. It has to be restrictive if you want to couple it to specific objects like VMs and such. It would be too restrictive only if you are going to add a generic implementation of a container holding objects which can be referenced by generic keys. You are trying to add a hybrid. Something which is generic enough to allow anonymous naming, but specific enough that it has to have an "active" field. [1] I don't really see the point in trying to abstract the contents of a "object list". I see value in having a object/set of APIs which would basically allow multiple keys for an entry in a hash table (for any possible implementation of this). All of such can be done on a virObject and you don't need any custom wrapper object which holds certain anonymous properties. The wrapper object you are adding here doesn't seem to add any value, since you can't really remove the name or UUID value from the internal objects, so that still would be duplicated. [...] [1]