Hi all,
As the use of multiple-inheritance UNO interfaces increases, people
start to stumble over one specific problem: Assume there are two
interfaces X1 and X2, each with a method named foo. Then, you cannot define
interface X3 {
interface X1;
interface X2;
};
as UNO does not support method overload (even if the two methods named
foo have different signatures).
The general solution to this problem should be to guess which of the two
interfaces X1 and X2 is "more important" at X3 (i.e., the methods of
which of the two will be called more often), to inherit X3 from the more
important one, and to have some additional method to obtain the less
important one:
interface X3 {
interface X1;
/**
Get the X2 interface of this object.
Logically, X3 should inherit from both X1 and X2.
However, because both X1 and X2 define a method foo,
this is technically not possible. Therefore, the
interface X2 of this object can be obtained through
this method (which is more explicit than using UNO's
general query-interface mechanism, which will also
work). It is guaranteed that the returned reference
is not null and references the very object on which
this method is called.
*/
X2 get2();
};
One case where this problem occurs in practice is with
com.sun.star.lang.XComponent and
com.sun.star.document.XEventBroadcaster. I just learned that Andreas
Schlüns is probably going to add a new
com.sun.star.document.XDocumentEventBroadcaster (or similar) that will
have the same functionality as XEventBroadcaster, but using method names
that do not clash with XComponent. Thus, in this specific case the
solution can be to inherit from XDocumentEventBroadcaster instead of
XEventBroadcaster (which you might still want to offer via the
query-interface mechanism on your objects, for backwards compatibility),
instead of using the general solution outlined above.
Another point is that the best solution to this problem is to avoid
method name clashes in the first place. This is of course not always
possible, but there has been a culture of choosing long names over short
ones in the com.sun.star interfaces, and we should continue that.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
