Bro currently misuses the any type to describe "handle" or "descriptor"
types. Consider for example the MD5 function family, which take a state
object as first argument. At the scripting layer, it has no other
purpose than mapping to the corresponding MD5 state at the core. Users
don't use it otherwise. There exists no dedicated handle type in Bro,
although it wouldn't be complicated to add one.
I am encountering this during the review of Soumya's cardinality counter
code. Before continuing with the merge, I propose to add a dedicated
opaque type that has the form:
opaque of T
where T is an identifier from the parsers perspective. For example, this
would entail a signature change from
md5_hash_init(idx: any): bool
to
md5_hash_init(idx: opaque of MD5): bool
At script load time, Bro can ensure type safety by performing string
comparisons that come with the identifier. Such a type would finally add
structure to the process of adding new BiFs and related extensions.
There exists no dedicated handle type in Bro,
although it wouldn't be complicated to add one.
Yes, having a handle type in Bro would be incredibly handy.
I am encountering this during the review of Soumya's cardinality counter
code. Before continuing with the merge, I propose to add a dedicated
opaque type that has the form:
opaque of T
Not sure I like this. It seems too similar to the current syntax of tables and vectors (I do want to see the vector syntax eventually though). It looks like T would be a yield value.
In the spirit of keeping the discussion going I'll try and propose an alternate syntax.
md5_hash_init(idx: opaque of MD5): bool
opaque<MD5>
I'm not sure I like this either because it would be adding new tokens to the parser, but it is a pretty new concept to add to Bro too.
Not sure I like this. It seems too similar to the current syntax of
tables and vectors (I do want to see the vector syntax eventually
though). It looks like T would be a yield value.
I see the similarity to other language elements rather as a consistent
form of integration. Why would the "T of Y" syntax only pertain to
container types? Admittedly, we have currently no other uses, but looks
like a reasonable one to me.
opaque<MD5>
While this looks good to folks familiar with C++ and templates, it looks
like an exceptional one-off to the Bro language. As you said, it would
involve tweaking both lexer and parser, and when is a about to happen,
we should rethink the added value.
I see the similarity to other language elements rather as a consistent
form of integration. Why would the "T of Y" syntax only pertain to
container types? Admittedly, we have currently no other uses, but looks
like a reasonable one to me.
> opaque<MD5>
While this looks good to folks familiar with C++ and templates, it looks
like an exceptional one-off to the Bro language. As you said, it would
involve tweaking both lexer and parser, and when is a about to happen,
we should rethink the added value.
Yeah, I agree with Matthias here on both of these points. "opaque of T"
strikes me as reasonable syntax.
