rfc: refactoring msxml3 to get rid of aggregation

[Michael Karcher]

Hi Jacek.
> Hi Michael,

> Casting function in vtbl is not an acceptable solution. If you have to 
> do that, it means that the design is bad.
So in short that means that using deriving for objects to implement
derived interfaces is not possible in Wine, as it is not cleanly
implementable in plain C. Too bad, but I also don't like casts in the
vtbl, as they are definitely not typesafe. I think one could come up
with a preprocessor macro hack that enforces typesafety and results in
plain casts, but macro-magic is rightly frowned upon in wine. I don't
think anyone would like to maintain the macro-mess that would be needed
(including myself).

> > Any oppions on that?
> I think other solution would be better. There is no reason for xmlnode 
> object to implement any interface.
xmlnode could provide a default implementation for most of the
functions, so one only has to override the functions that need specific
handling. If derivation could be used, one does not have to write tons
of separate stubs that just do the same, namely forward calls to the
xmlnode default handlers (I would call that poor man's derivation),
which would kill a lot of boilerplate source code, and thus reduce
executable size (who needs 300[1] functions containing [if gcc optimizes
correctly, not verified] just one jump instruction if the address of the
target could have been put instead in the vtable) and improve
performance a bit. On the other hand, 300 jumps instructions (if the
optimizer works...) are just 1.5 kilobytes, and that shouldn't hurt that
much on modern computers.

[1] order-of-magnitude estimate.

> All its child objects already have IXMLDOMNode interface.
Yes, of course, as the child objects implement interfaces that are
derived from IXMLDOMNode (either directly or indirectly).

> xmlnode could be a common struct stored by child 
> objects and there could be set of function with common method 
> implementation.
Right. That is quite like the direction I was also heading to. The extra
memory allocation and use of COM aggregation for the xmlnode object
definitely seems like overkill, and is also avoided by the containment
approach you suggest.

> This way we could also avoid ugly tests for node type in 
> node.c, because we can handle the difference outside node.c.
Very good point, didn't take a look at them. These tests should get
expunged and replaced by different implementation chosen by the vtable
of the IXMLDOMFoo imlementing objects.

Thanks for your input,
  Michael Karcher