mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Brégier <fred.breg...@free.fr>
Subject Re: DemuxingIoHandler methods marked final
Date Wed, 08 Oct 2008 18:40:34 GMT
Well, presenting that way, what could I say ?
Probably to carefully document the DemuxingIoHandler
class in order to let know to the programmer that he/she has two options :

1) Using the MessageHandler and ExceptionHandler but 
    really not changing those three methods by overloading them
or
2) Not using at all (really not at all) the MessageHandler and ExceptionHandler
    and so with the obligation to overload those three methods
    in order to get the internal logic correct (as in 1.1.X version of Mina).

Of course, anyone can read the code of Mina, but how many times
I do it with external jar ? Almost never. I read the API and the doc in it.
So, making them not final could be OK if it is clearly warned in the API doc
so that an end user (like me) doesn't get it.

Indeed, just as my personal example, in 2007, my bad was that I didn't get
this point when I migrate to the 2.0 version and I wrote both overload
for Demux and for MessageHandler, which becomes completely wrong.
I have the same kind of code as you mentioned in your answer.
If I recall well, it was about 7 MessageHandler to rewrite, done in an half hour.
That was the origin of those posts and Trustin made the change as mentioned
in the mailing list, but only in version 2.0 of course.

I'm still not sure that letting something known as bad to be possible,
but I get your point that your client application has so much code to
change that it could be really painful.

So, go but insert a warning in the API doc.
WDYT ?
Frederic


Mime
View raw message