Re: [libvirt] [PATCH] esx: Fix dynamic dispatch for CastFromAnyType functions
2011/4/27 Daniel Veillard <veillard(a)redhat.com>:
On Wed, Apr 27, 2011 at 09:35:32AM +0200, Matthias Bolte wrote:
> 2011/4/27 Daniel Veillard <veillard(a)redhat.com>:
> > Not sure I fully understand but looks regular and okay, ACK :-)
> >
> > Daniel
> >
>
> Actually, this shows that even I'm not always aware of all the details
> in the ESX driver, otherwise this regression fix wouldn't have be
> necessary and I wouldn't have needed two attempts to get it right. So
> don't feel too bad about not fully understanding it :)
>
> This is probably a sign that I should try to reduce the complexity and
> levels of indirection in the generated code and the code generator.
Reminds me of docs/apibuild.py , that's code I wrote like 10 years
ago for libxml2, and I certainly don't remember all the subtelties,
it's certainly not very nice code, but being a generator and automated
parser the good point is that I don't have to remember it, and very
seldomly hack it. I think there is no shame to having "imperfect" code
which does this kind of things as long as it's done in a generic enought
way that you don't have to tweak it often.
If the extra indirections don't cost anything (except extra code) then
maybe it's fine keeping. I would say the main driver to clean such code
would be if you feel others need to hack on it and it need to be cleaner
and easier to understand.
Daniel
The generator is in a state where adding new stuff from the vSphere
API boils down to just adding a definition to the input file in most
cases. For some things list in the generator need to be tweaked that
define what features should be generated for a specific object type.
IIRC in most cases this could be automated too as the generator could
detect this by analyzing the input file better. This way the generator
becomes more complete and others don't need to hack on it and the code
generation process to add new stuff from the vSphere API.
About the complexity in the generated code: For example parts of the
type handling currently nest three levels of macros, because it's
"convenient" and reduces manual code duplication, but it becomes
harder to understand and get right when I need to hack on it. That's
the motivation behind possibly simplifying the generator related stuff
:)
Matthias