Frank Schönheit wrote:
Hi Jürgen,
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.
Well ... This is _not_ a C++ implementation problem, this is a real
UNO/IDL problem!
I modeled new interfaces after existing services, with the following
structure:
XFormControlModel
+- XUnoControlModel
| +- ...
| +- XPropertySet
+- XFormComponent2
+- ...
+- XPropertySet
IDLC does *not* complain here, and honestly, it would seriously reduce
the usefulness of multiple inheritance. As said, this is a real-world
example of creating "new UNO" interfaces from "old UNO" services.
IDLC only complains with if the direct base iterfaces of XFoo produce a
name clash (e.g. if you include both XPropertySet and XMultiPropertySet,
since both declare a getPropertySetInfo). It does not complain if the
name clash is deeper down the inheritance hierachy.
idlc would complain if XFoo would inherit directly from XPropertySet.
Seems to be a problem.
And you are right that it isn't possible to transform all old services
into multiple inheritance interfaces 1:1.
The design have to be changed. You can still define attributes at your
base interfaces and you should define XPropertySet at the root of your
inheritance tree for example XFoo.
The PropertySetMixin helper takes care of that. But of course it is more
complicate for aggregation or own implementation base classes.
Besides the concrete XPropertySet problem: The first instance where I
stumbled upon this wa
Reference< XFoo > xFoo = getSomeFoo();
Any aProperType = xFoo->queryInterface( someUnoInterfaceType );
Here, queryInterface is obviously also ambiguous, as soon as XFoo uses
multiple inheritance. So, if IDLC would really prohibit nameclashs in
indirect base interfaces, it should consequently prevent multiple
inheritance at all. Probabaly not what "UNO ease of use" was intended for :)
So, the question remains: Is it feasible to do what Jörg suggested:
Extend cppumaker so it disambiugates methods of interfaces which are
inherited indirectly multiple times? E.g., let cppumaker generate
class XFormControlModel
: public XUnoControlModel, public XFormComponent2
{
...
// disambiguate XPropertySet
// inherited from both XUnoControlModel and XFormComponent2
virtual Reference< XPropertySetInfo > SAL_CALL getPropertySetInfo( )
throw (RuntimeException) = 0;
virtual void SAL_CALL setPropertyValue(...) throw(...) = 0;
virtual Any SAL_CALL getPropertyValue(...) throw(...) = 0;
...
};
needs to be evaluated ...
Juergen
?
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
