Steve Ulrich wrote:
Seriously, you make a good point here, and enlighted the reason we have
these methods. And after a day looking at those preAdd and postRemove
(well, not a full day !), I think it's better to have those two guys
called directly when you do a add() and remove() than to have an
explicit init() method, generally speaking. But there is another
Hmm.. dedicated init and destroy methods would help to make the code clean. If
they don't exists, some will call it preAdd/postRemove, others init/destroy,
beforeInsert/afterRemove...
Additional (and increasing with the number of method-pair-names) there's a
possibility to forget to call the methods and just doing add/remove and getting
errors.
I'm not sure I see what you mean here. Let me clarify :
- should we have init/destroy(session) methods replacing the
preAdd/postRemover methods ?
- or should we have init/destroy methods not related to the session,
with the pre/post methods ?
<snip/>
so : I think that we need to rethink about what those two methods do,
in
order to protect the user against dangerous hidden mistakes...
IMO, the normal case is that a filter will only be added once.
Absolutely. But some peeps are using some filters more than once. For
instance, Ashish is using the ExecutorFilter more than once to reproduce
a SEDA like system. (IMHO, a very special use case).
If they're added more than one time, the filter must be responsible for that.
Agreed.
Maybe an additional interface can provide the neccessary methods to handle that
case. If the Filter does not implement it, it can only be added once.
Yep. Good idea.
This way, the "if (chain.contains(this))" could be removed from the filter
implementations.
Those checks are pretty painful. But if the filter can be added only
once by design, we need to have them, otherwise we rely on user's
wisdom, which is dangerous ;). Ie, I think they are like a safety net
for the base case. Not sure we need them though, this is much a design
decision than a technical one.
<snip/>
- if we don't need those initialization/destruction, then default to a
flag being set indication the filter's status (initialized/removed)
- throw an exception if the status is incorrect when he use the filter
(protecting the user if he forgets to initialize the filter).
Sounds a bit comlicated from a users point of view. Maybe we can use an
interface here, too.
The add and remove method can check if the filter implements the interface and
call the method as needed.
Yeah. I have to rethink this part a bit...
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
