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

Jon Siwek jsiwek at corelight.com
Wed Feb 20 10:08:17 PST 2019

On Tue, Feb 19, 2019 at 10:55 PM Robin Sommer <robin at corelight.com> wrote:
> On Tue, Feb 19, 2019 at 08:28 -0600, Jonathan Siwek wrote:
> > we pick points in time as an "event" and associate various bits of
> > data with them, then users declare their interest in some subset of
> > that data. Most natural way for them to do that seems to be by naming
> > each bit of data.
> I agree with all of that in principle, but for me it would need a
> different syntax to become practical. The current syntax for events
> implies certain semantics just by being similar to so many other
> languages that don't do named-based matching for parameters.

Granted, but not sure how problematic that is in reality.  E.g. you see this:

    event foo(version: string, method: string);

    event foo(method: string) { ... }

Seems intuitive that one understands the "method" parameter means the
same thing in both the definition and handler.  This is a fundamental
reason why, in human's general use of language, we name things in the
first place: things that share a common name share a common meaning.
Or what else is there to be confused about with name-based param
matching ?

A side point is that maybe some other languages are just following the
crowd and actually would benefit from name-based param matching in
some cases.  Maybe they just haven't thought about it (I have, that's
why I'm still trying to hang on to this :)).  Doesn't mean we
shouldn't evaluate Pros/Cons of breaking apart from the crowd.

I haven't seen anything so far that was a convincing Con to me, but
always possible I've missed some way name-based param matching could
conflict with an existing or future feature of the language -- those
would be particularly convincing Cons for me.

- Jon

More information about the zeek-dev mailing list