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
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
