Re: Bag IDL



Dietmar Maurer wrote:
 
> We have added this to make it more obvious that a PropertyBag is
> also an EventSource. Please do not remove it.

If your intentions are to document the availability of signals/events,
this falls well short.  

The user is still forced to drill through the code to determine what
types of events are produced and what nebulous string name must be
parsed out of the event source's generic event production voodoo. 
Instead of adding methods to document queryable interfaces, perhaps
adding comments on the related interface's usage would be better.

The old PropertyListener interface provided a well defined API for the
types and format of events produced by a bag.  If this event
source/generic listener paradigm is going to be useful, we need a good
consistent way to not only document the events that an interface
exposes, but also decode them into a parameter list on the client side. 

I personally don't intend to expose EventSource in my components. The
footprint that is saved in eliminating [add|remove]Listener boilerplate
methods and a simple Listener object is more than offset by the addition
of complex CORBA_any encoding and decoding and string based event name
parsing.  I think it is more appropriate to provide a specialized
listener that emits specialized events, instead of forcing clients to
implement hairy CORBA_any parsing signal callbacks.

Mike




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]