On Tue, Feb 5, 2019 at 7:40 PM Robin Sommer <ro...@corelight.com> wrote:
> The following would be even worst in terms of confusion: > > global my_event: event(a: string, b: string); > event my_event(b: string) > > Now I need to know if the language goes by order of parameters or by > parameter name. The issue may be exaggerated because we're using contrived parameter names. If we make it a bit more real (still "shortened" for sake of example): http_request: event(method: string, version: string); event http_request(version: string) { ... } The "parameter order vs. name" issue doesn't even cross my mind here because the intent is clear -- I understand the meaning of the handler's parameter because the original author of the event chose a meaningful and useful name for it (which will be the common case). That's all the reader cares about -- understanding the meaning of any given parameter. > I do see the appeal of making things just work when event handlers > change, but is there really no different way to support that? If the goal is to avoid breaking user-code, I don't think we're in a position to do anything else. For example, we have: global my_event: event(a: string); And we want to add a parameter: global my_event: event(a: string, b: string); The user has already written their handler as: event my_event(a: string) { ... } We can't magically change that user's code. We have to, somehow, let that work as it is, without user intervention. - Jon _______________________________________________ zeek-dev mailing list zeek-dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev