Re: Does anybody want to replace base handler ?

Hi Holger,
I agree the API is nice. It looks a lot like my first MDR API (back 
before February 5, before I refactored it). But at that time I had also 
different event sources for assiciation, instance, etc. Then during the 
February I have refactored and simlified it and during this 
simplification I also removed the bitmask thing. The only thing that 
remained was the isOfType method in MDRChangeEvent enabling listeners to 
filter the events themselves. It seemed to me that this mechanism was 
sufficient. I would like to see the implementation of the API to see if 
it is that much more efficient to filter events inside of MDR than 
inside of each listener (I expect that you will need to have some "if {} 
else {}" clauses in the listener even if it will use the bitmask).
Checking the bitmask on each listener can be reduced by grouping several 
listeners registered under the same bitmask in some kind of hashmap 
which would speed things up given that there are many listeners 
registered under the same bitmask. But in case of EVENTMASK_ALL and 
EVENTMASK_ON_.. this is no win over the previous proposal with no 
bitmasks. Do you expect to have many listeners on bitmasks other than 
these two?
Another thing I am concerned about are the names of the constants. What 
is the difference between EVENTMASK_ON_... constants in MDRChangeEvent 
class and EVENTMASK_... constants in subclasses of MDRChangeEvent? Can 
we remove EVENTMASK_ON_ constants?
I don't think that EVENTMASK_BY_... constants are that useful. 
EVENTMASK_ALL can be used in most cases instead of them. Should they be 
removed?
Martin


Holger Krug wrote:
> On Mon, Jul 15, 2002 at 02:12:31PM +0200, Martin Matula wrote:
> 
>>I would rather like to have a patch not containing the changes to 
>>handlers.
> 
> 
> OK.
> 
> Please review my new API proposal. I chose to give my proposed
> MDRChangeSource.addListener(MDRChangeListener listener, int mask) a
> try and implemented/documented it. It don't know what you think about
> it, I know you were against it, but in implementing/documenting it, I
> realized that it gives really a nice API.
>