On 30 Nov 2017, at 10:22, Jan Grashöfer wrote: > On 30/11/17 19:01, Johanna Amann wrote: >>> 1. Thinking of handlers that may change values and are associated >>> with a >>> priority, hooks come to my mind (e.g. Intel::extend_match). Are >>> functions preferable compared to hooks here? >> >> In this case - yes. The problem with hooks is that they cannot return >> a >> value, which is used here to let user change (or reject) changes to >> options. :) > > The Intel::extend_match hook allows changing values or rejecting as > well. If the "chain of hooks" is "broken", i.e. one hook executed a > break statement, the call to the hook returns false and (in that case) > the log write is rejected. Otherwise, all changes made to the hook > arguments inside the handlers are propagated allowing changes.
Ah, you have a point there it is possible to do it like that, I did not think of that. I honestly also never liked modifying the values that are passed in arguments; this is for example also theoretically possible for events, but something that we have avoided to use in practice so far. Functionally they are, however, obviously equivalent. I think I prefer functions in this case from a stylistic point of view. I am happy to change it over to hooks though if there is a consensus that that is the more fitting approach here. :) Johanna _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev