Adding an implemented UNO interface

[Michael Stahl]

On 05/09/2023 14:29, Lionel Élie Mamane wrote:
> On Tue, Sep 05, 2023 at 08:34:56AM +0200, Noel Grandin wrote:
>> On Mon, 4 Sept 2023 at 21:54, Noel Grandin <noelgrandin at gmail.com> wrote:
>>> On Mon, 4 Sept 2023 at 20:43, Lionel Élie Mamane <lionel at mamane.lu> wrote:
> 
>>>> becomes an ambiguous base of class bar, as it is derived from twice
>>>> :-|
> 
>> Likely you will have to implement disambiguation overrides like:
> 
>>     virtual SAL_CALL void setFoo() override { Baseclass::setFoo(); }
> 
> Pierre is more courageous than I anticipated, and it looks like he
> will just change grault (in reality OMetaConnection) to declare
> implementation of qux2 (which is css::sdbc::XConnection2) and change
> all derived classes that derive from grault to actually implement
> qux2.
> 
> An alternative idea I have is to make grault a templated class,
> templated on which interface(s) it declares. Will try to do that.
> 
> Also, since I'm starting to think that we should maybe split qux2 into
> several different interfaces that can optionally be implemented or
> not, I would like to understand the UNO interface mechanism details
> better: is there a difference between

it depends ... i think in terms of what is being produced from the IDL 
files, these 2 examples are the same.

but the intent is a bit different:

> interface qux2: qux
> {
>    void method();
> }

this is a single-inheritance interface; with this syntax only one 
super-interface can be specified.

usually a UNO service would be composed from multiple orthogonal 
single-inheritance interfaces (every interface inherits implicitly from 
XInterface), i.e. the service IDL file would list them all.

> and
> 
> interface qux2
> {
>    interface qux;
>    void method();
> }
> 
> and if yes, what is the difference?

this is a multiple-inheritance interface.

it exists mainly for one purpose: the "new" style UNO services are not 
composed directly from multiple orthogonal interfaces - instead there is 
an additional "layer" of one multiple-interitance interface that is then 
the interface mentioned in the service.

this has the advantage for the user that the factory can return the 
multiple-inheritance interface for the service and many different 
methods can be called without queryInterface.

but in this case, i suspect it may be considered unidiomatic if the 
multiple-inheritance interface specifies additional methods in addition 
to the ones inherited, so for this example i'd prefer the first one.