[Bro-Dev] changing Notice::policy mechanism

[Siwek, Jonathan Luke]

Here's an idea that combines a lot of the previous discussion -- how about we implement the capabilities of a "switch" statement, except we use a new type of function to do it.  So there would then be function types designated by keywords "function", "event", and "switch".  The "switch" would be like a "function" in that it can be called synchronously and doesn't have to be scheduled like an "event", but it's also like an "event" in that you can implement multiple bodies for the same "switch" identifier and designate &priority for each.  Additionally, a new attribute called &case can be used with "switch" functions, and the argument to it is evaluated each time the function is called to determine whether or not to actually execute a given body.  Also, if the body of a "switch" function returns as a result of a "break" statement, then that aborts the execution of the "switch" function and no more bodies get processed.

So an example of how it works in code form would be...

type TriggerType: enum {
    Good,
    Bad,
    Ugly,
};

type MyInfo: record {
    a: count;
    trigger: TriggerType;
};

# this declaration of the switch function would be optional (same as how functions work now)
global trigger: switch(n: MyInfo);

switch trigger(n: MyInfo) &case=(n$trigger==Bad) &priority=-5
    {
    this_stuff_never_happens();
    }

switch trigger(n: MyInfo) &case=(n$trigger==Bad) &priority=10
    {
    do_stuff();
    break;
    }

switch trigger(n: MyInfo) &case=(n$trigger==Ugly) &priority=1
    {
    do_other_stuff();
    }

event bro_init()
    {
    local rec: MyInfo = [$a=13, $trigger=Bad]);
    trigger(rec);
    # rec can be inspected here for meaningful modifications
    }

That should give everything we want:

(1) case expressions allow conditional application of logic
(2) logic can be prioritized
(3) logic can be short-circuited
(4) easy to understand how a user can refine/insert new logic for a priority/condition of their choosing
(5) its use should be generalizable and not specific to "policy" evaluation

One downside might be that it's not the typical "switch" people could be familiar with, but I don't think it's that confusing to take previous knowledge of how "switch" statements work when trying to understand how to use "switch" functions.  I also don't think this would preclude the later implementation of "switch" in the usual statement form, it's just that implementing it using functions satisfies the "refinement" requirement more easily.

    Jon