[Zeek-Dev] support for event handlers using a subset of parameters

Jon Siwek jsiwek at corelight.com
Fri Feb 1 08:16:23 PST 2019


On Thu, Jan 31, 2019 at 6:29 PM Vern Paxson <vern at corelight.com> wrote:

> > * user doesn't care about parameter 'a', so they shouldn't have to list it
> > * it makes it easier for to deprecate/change event parameters
>
> This seems like a pretty niche pair of benefits.  Is there a compelling
> use-case that's motivating this change?

The compelling use-case I'd say is the ability to change/deprecate
event parameters without suddenly breaking people's code since that
has come up many times already.  I briefly skimmed NEWS for just the
last 2.6 release and count 5 times we broke an event signature where
this patch would have helped.

I think there's also some other higher-profile changes to event args
we haven't moved forward with because we didn't want to break user
code that this would help with.  Old example from unresolved ticket:

https://bro-tracker.atlassian.net/browse/BIT-1431

> One thing I initially wondered was whether this was going to tie our hands
> in the future if we want to introduce C++-style overloading.  However, it
> looks like you've implemented this based on matching the names in the
> declaration rather than the types, so that should be okay.

Also this change only effects events and hooks, not functions.  The
semantics are different enough that maybe we would only want
overloading for functions anyway.

That is, functions have a single, fixed implementation/body that is
defined by the *author*, so you may want to re-use the same name for
something implemented in different ways.  The *user* is the one that
calls the function.

Hooks and events have multiple implementations/bodies that are defined
by the *user*.  The *author* is generally the one the generates
(calls) the event/hook.

So if the event/hook name were overloaded, it's a bit confusing -- the
user now has to decide between different signatures to handle, each
containing different data sets and maybe neither contains the set they
want (so now they handle two events of the same name instead of one).
Really, an event is a unique name with some amount of data
(parameters) associated with it and may always be generated with the
full data set -- the user then chooses which data they are interested
in by defining that explicitly in the handler's parameter list.

- Jon


More information about the zeek-dev mailing list