On 03/08/2016 09:46 AM, Markus Armbruster wrote: > Eric Blake <ebl...@redhat.com> writes: > >> Every non-implicit entity is associated with an 'info' >> dictionary, but it is not easy to reverse-engineer the name of >> the top-most entity associated with that 'info'. Our use of >> 'case_whitelist' (added in commit 893e1f2) is thus currently >> tied to the owner of a member instead; but as the previous patch >> showed with CpuInfo, this requires whitelist exceptions to know >> how an implicit name will be generated. > > Why is that a problem?
Not necessarily a bad problem, but a bit annoying. If a developer modifies a .json file and adds an improper name, then they will get an error message that tells them that they need to fix their naming conventions (hmm, the error message doesn't even point them to the whitelist - see args-member-case.err). If the developer figures out that the whitelist will let them avoid the error, they still have to figure _what_ name to add to the whitelist, and without this patch, they have to determine the generated name for the implicit struct (which may not be constant, since we are discussing about alternative names earlier in the series other than something that flattens to a public 'struct _obj_...' in violation of file-local naming scope). The goal is thus to make the whitelist tied only to names mentioned in the .json file, rather than dragging generated implicit names into the mix. But it is cosmetic; we could live without the patch and stick to generated names in the whitelist, just as easily. > >> While we have a ._pretty_owner() that maps from implicit names >> back to a human readable phrase, that produces more than just a >> plain top-level entity name. What's more, the current use of >> ._pretty_owner() is via .check_clash(), which can be called on >> the same member object more than once (once through the >> standalone type, and a second time when used as a base class of >> a derived tpye); if a clash is only introduced in the derived >> class, using ._pretty_owner() to report the error on behalf of >> the base class named in member.owner seems wrong. Therefore, >> we need a new mechanism. > > Now I'm confused. Are you fixing suboptimal error messages? No, I was trying to document why ._pretty_owner() (which is our only pre-exisiting map from Python objects back to pretty type names) is insufficient for the task at hand (namely, what is the pretty name of the type to add to the whitelist, if we don't want generated implicit names in the whitelist). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
