Frank Schönheit - Sun Microsystems Germany wrote:
Hi,
using the "new" UNO features, in particular multiple inheritance, to
excess :), I stumbled upon the following problem:
Let's say we have
interface XBar1 {
interface XPropertySet;
};
interface XBar2 {
interface XPropertySet;
}
interface XFoo {
interface XBar1;
interface XBar2;
}
Now, in the UNO C++ language binding, consider:
Reference< XFoo > xFoo = getSomeFoo();
xFoo->getPropertyValue( somePropertyName() );
This yields a compiler error that "getPropertyValue" is ambiguous.
My first attempt to resolve this was
xFoo->XBar1::getPropertyValue( somePropertyName() );
This compiles fine, but yields a linker error that the symbol
XPropertySet::getPropertyValue cannot be found. Thinking about it, the
linked is probably right to reject my stupid attempt :), but then I
still have my problem.
Okay, a working alternative to resolve this is
static_cast< XBar1* >( xFoo.get() )->getPropertyValue(
somePropertyName() )
This compiles and links fine. However, it has the disadvantage that
users of XFoo must *know* at least one base interface of XFoo which
unambiguously provides the XPropertySet functionality - which is
inconvinient.
Yet another alternative is
Reference< XPropertySet > xFooProperties( xFoo, UNO_QUERY_THROW );
xFooProperties->getPropertyValue( somePropertyName() );
This relieves the user from knowing the base class hierarchy of XFoo,
but the penalty is additional runtime costs. Also, it contradicts the
intention of the new UNO features, which were introduced to *save* the
syntactic and runtime overhead of all those queryInterface calls.
Although i haven't a satisfying solution for you, the new UNO features
were introduced to eliminate most of the queryInterface calls not all
;-) You have to use queryInterface still for optional interfaces.
And of course if you re-declare the ambiguous interface methods and
handle the ambiguity in your implementation it should be no problem for
the user.
In IDL you can't get this situation because the idlc complains if you
inherit more than once from XPropetySet (directly or indirectly).
In your implementation you have to take care of this depending on your
specific inheritance hierarchy or base classes, helper classes.
Juergen
So far, I didn't find any satisfying solution to this problem.
Did I overlook something?
Are there better solutions in place ATM?
Are better solutions at least possible in theory (by, say, changing the
generated C++ header for XFoo to include a disambiguated
getPropertyValue method)?
Thanks & Ciao
Frank
PS: Interestingly, the Java language binding does not seem to suffer
from this problem.
XFoo foo = getSomeFoo();
foo.getPropertyValue( somePropertyName() );
compiles fine ...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
