[g-a-devel]Registry.idl and aggregation
- From: Bill Haneman <bill haneman sun com>
- To: gnome-accessibility-devel gnome org
- Subject: [g-a-devel]Registry.idl and aggregation
- Date: Wed, 12 Dec 2001 10:35:11 +0000
Hi Michael and all:
You've mentioned using aggregation for Registry before, and even
included the following lines in the TODO list:
+ kill the getDeviceWhatnot - and use queryInterface,
don't inherit from the Listener interface - use aggregation
As I've mentioned before, I don't agree. I have been continuing to
think about this however, in the interests of flexibility. However I
find that the more I consider the matter, the more convinced I am that
the current IDL is more appropriate. Though I don't want to belabor
this point I think I can put my thinking succinctly.
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. At the moment that reveals that:
(a) Registry implements the Listener interface, and
(b) Registry contains an instance of the DeviceEventController
interface, documented therein.
If we aggregate and use queryInterface, we lose both of those pieces of
information from the IDL. 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).
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. Aggregating the three would leave
us with the same uninformative IDL (no indication that RegistryDaemon
must implement these other interfaces).
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.
] [Thread Prev