Iterate interfaces in the MRO reversed order #105
Conversation
|
Hello @arkq Thank you for submitting this pull request. Could you add some unit tests to verify the behavior? Hmmm... I plan on adding a simple introspection parser in the next version. Maybe that could be used to verify the order of introspection interfaces. |
Yes I can add some tests for that, but not before the next week. |
Iterating the MRO in the reversed order will allow to add interfaces to the given object in a well-defined way - always starting from the base class. Such ordering will be compatible with adding interfaces manually one by one.
The introspection data depends on the libsystemd implementation (that was my first try when implementing test cases for that). Instead of that I've added a test which checks the order of registration, because this library controls only that part. That way, the test will be still valid when/if systemd accepts the ordering fix patch. |
|
Thank you for implementing changes. I will try to review this next weekend. I want to verify how the other users of |
|
I tested it a bit locally. Looks like controlling the iteration order is not required for now. I will add such option once it is needed. Thank you for your work @arkq ! |
Iterating the MRO in the reversed order will allow to add interfaces to the given object in a well-defined way - always starting from the base class. Such ordering will be compatible with adding interfaces manually one by one.