« Return to Thread: rfc: refactoring msxml3 to get rid of aggregation

Re: rfc: refactoring msxml3 to get rid of aggregation

by Jacek Caban-2 :: Rate this Message:

Reply to Author | View in Thread

Hi Michael,

Michael Karcher wrote:
> Any oppions on that?

I think other solution would be better. There is no reason for xmlnode
object to implement any interface. All its child objects already have
IXMLDOMNode interface. xmlnode could be a common struct stored by child
objects and there could be set of function with common method
implementation. This way we could also avoid ugly tests for node type in
node.c, because we can handle the difference outside node.c.

> I (obviously) think that b is the right solution,
> but as a quick grep over the Wine source code revealed, this solution
> seems to be used nowhere. Is that because this is the first place where
> deriving makes sense or is that because I'm completely off-track?
>  

Casting function in vtbl is not an acceptable solution. If you have to
do that, it means that the design is bad.


Jacek


 « Return to Thread: rfc: refactoring msxml3 to get rid of aggregation