On 09/03/2012 02:27 AM, Tang Chen wrote:
Hi Chris,
I aggre with you on the "is a kind of" idea you said in another email.
But here, I don't quite understand the marshal method.
What do you mean by "convert vm instance into VMXML instance" ?
Do you mean class VM should also be a subclass of class LibvirtXMLBase ?
So it is like this:
LibvirtXMLBase(XMLTreeFile)
|
|
+---LibvirtXML(LibvirtXMLBase)
|
|
+---VMXML(LibvirtXMLBase)
|
|
+---VMInterfaceXML(LibvirtXMLBase)
|
|
+---VM(virt_vm.BaseVM, LibvirtXMLBase) # So that we can convert vm
# to vmxml.
|
|
+--- ......
Is this kind of convert like the deep copy in C++ ?
We just create another VMXML instance and copy the counterparts in VM
instance one by one.
Thanks. :)
Not exactly. The idea is to be able to convert an instance of one
class, into an instance of another class. The simplest 'brute-force way
to do this is by hand-coding the logic into a method. It would simply
query the properties of the source class, and and set them up properly
on an instance from self.__new__(). There are fancier ways to do it
involving translation dictionaries and additional functions/methods.
Generally, no multi-inheritance is required/necessary.
Though, now that I think about it, I'm not certain how useful it would
be anyway. For now, I think we just need classes for each kind of
"Chunk of XML" we're likely to encounter. As we come across need to
write test, we can add useful methods to appropriate classes.
For example, maybe adding a network interface to a VMXML instance means
you create a VMInterfaceXML instance, set it up how you want it, then
call vmxml.add_interface(vminterfacexml).
Another idea, could be to exploit the __add__ special method, and have
it use a big if type() == whatever block to sort out what's being added.
But from a test perspective, this looks nice:
vmxml += VMInterfaceXML(param, param, param)
Anyway, let's work on getting the very basic structure right first, then
we can add features over time (as we need them). Still, it's good to
think ahead, and plan these ideas out as a group, so thanks again for
sharing.
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
