Re: [g-a-devel]Registry.idl and aggregation

[Bill Haneman <bill haneman sun com>]

Michael Meeks wrote:
> 
> Hello Bill,
> 
> On Wed, 12 Dec 2001, Bill Haneman wrote:
> > Since the IDL is "the public interface" for libspi, one should be able
> > to glean a sufficient description of the interface from reading the
> > IDL.
> 
>         Or indeed the comments in it.
> 
> > (a) Registry implements the Listener interface, and
> > (b) Registry contains an instance of the DeviceEventController
> > interface, documented therein.
> 
>         Whereas really Registry implements three interfaces - a Listener
> and a DeviceEventController; which is rather different.
> 
>         Having (redundant) accessors is a good enough method for
> documentation - so one solution would be aggregation plus a
> getEventListener method.

It seemed to me that the original proposal was to eliminate the existing
accessor method, which I don't think is a good idea.  If we add an
accessor, then your proposal begins to look more attractive since my
primary concern is addressed.

> > If we aggregate and use queryInterface, we lose both of those pieces
> > of information from the IDL.
> 
>         This is true - indeed; this is the only concievable reason for
> this form of inheritance - but an accessor provides this without the
> conceptual problems of introducing a bogus interface inheritance. The
> Registry _interface_ is conceptualy a totaly different interface from the
> EventListener _interface_ - the fact that this implementation happens to
> implement both interfaces is not relevant.
> 
>         Interface inheritance is totaly different to implementation
> inheritance - especialy with an interface aggregation model such as bonobo
> provides. [ yes if you have implementation inheritance you neccessarily
> inherit interfaces - clearly - but we don't ].
> 
> >  Unlike the case with Accessible, where we use aggregation to good
> > effect, a Registry without DeviceEventController and Listener is not
> > very useful, since these two functions are key features of the
> > registry (as we currently define it).
> 
>         Quite - so we should contractualy specify - either with a comment
> in the IDL or by an accessor that these interfaces are in fact aggregated.
> 
> > An alternative might be to separately define Registry,
> > DeviceEventController, and Listener as separate IDL and create a
> > RegistryDaemon interface that inherits from all three, but I don't
> > think that you would find that any nicer.
> 
>         This is impossible. The interface aggregating metaphore would be
> totaly broken - you can only use single inheritance with Bonobo, period.
> Furthermore, CORBA can't cope with multiple interfaces having the same
> method name - so the ref/unref/queryInterface methods would all cause
> conflicts.
> 
> >  Aggregating the three would leave us with the same uninformative IDL
> > (no indication that RegistryDaemon must implement these other
> > interfaces).

By aggregating I meant omitting any interface inheritance from
Registry(Daemon) and only aggregating "quietly" via
bonobo_object_add_interface.  The IDL suggestion just below seems fine
to me:
 
>         The RegistryDaemon would be:
> 
>         interface RegistryDaemon : Registry,
>                                    DeviceEventListener,
>                                    Listener {
>         };

I wouldn't consider this aggregation in the sense of the previous
conversation, I would consider this interface inheritance (as distinct
from implementation inheritance which I agree is not particularly
attractive in our case).
 
>         which seems ample documentation to me. But again, we are not using
> a multiple inheritance paradigm.
> 
> > My feeling is that there is little lost by retaining the current IDL,
> > and less to be gained by adopting aggregation, and that such change
> > would come at the cost not only of some modest engineering effort, but
> > incur the loss of some clarity in the IDL.
> 
>         I tend to disagree - if at-spi is being put into the platform at a
> low level it needs to be a showcase of good quality design and coding. And
> thus it needs to get this right.

I think it's arguable whether the current approach is "not right".  One
problem with adding an accessor for the listener interface is that it
makes the use of Registry more cumbersome (as would queryInterface).

>         Can you consider removing the inheritance, doing the aggregation
> and having 2 accessor functions - so at least we are symetrical ?

I think the asymmetry reflects the functional relationships.  The
relation of the Registry to it's Listener interface seems quite
different from that to its DeviceEventController, to me.

>
>         Regards,
> 
>                 Michael.
> 
> PS. I paste again my article from the 'self-help' series:

Entertaining as always, I have already read it this week ;-)


-Bill