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

[Michael Meeks <michael ximian com>]

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.

> 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).

        The RegistryDaemon would be:

        interface RegistryDaemon : Registry,
                                   DeviceEventListener,
                                   Listener {
        };

        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.

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

        Regards,

                Michael.

PS. I paste again my article from the 'self-help' series:

* Inheriting vs. Aggregating.

	By cunningly opening a bumper value, super size, 'new
formula', can of worms, I plan to bring Gnome productivity to a total
halt so here goes: I've seen interfaces that look like something like
this[1]:

	interface Foot : Bonobo::BodyPart {
		long  getNumberDigits ();
		void  setCompressiveForce (double forceInNewtons);
	};

	Whilst all well and good [2] there is no particularly good
reason to derive a Foot from BodyPart. Indeed, it ties the perfectly
generic and re-usable Foot interface to a body, and ignores the
thousands of lattice propelled ACME mechanical feet not to speak of
the humble prosthesis.

	Consequently before inheriting consider -

		* Do I really need to.

		* Is the derived interface unarguably inextricably
		  intertwined with the parent.

		* Why my interface is totaly non-generic; should I not
		  be re-using a generic interface, such as a property
		  bag in the above example.

		* Whether the IRS inheritance tax form 7165B is really
		  worth filling in, wouldn't it be better to leave
		  everything to Battersea Dogs Home ?

	I have seen inheritance badly misused, please write nice
separate generic interfaces and aggregate them together.

	Also, when you see a huge and cumbersome interface replete
with get and set methods, carefuly consider using a PropertyBag
instead.


-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot