On Wed, Sep 5, 2018 at 6:47 PM Vern Paxson <v...@corelight.com> wrote:
>
> > I think the right solution for this is to introduce a new BroType called
> > a NamedType. A NamedType has an identifier, an underlying BroType, and a
> > set of attributes. When a NamedType is constructed ...
>
> Huh, turns out there's already a "TypeType", which is the equivalent.
> All I need to do, I believe, is allow these to have attributes.
My recollection is TypeType is the type that a value gets when the
stored-value is actually just a type and doesn't quite fit what's
needed here.
Take the original example:
type a: table[count] of count &default = 5;
type b: a &read_expire = 1 min;
Declaring a variable of type 'a' or type 'b' doesn't mean that the
values stored in that variable are types themselves, they're still
just storing values of the table-type (but with different attributes
depending on 'a' or 'b').
Other ideas I'm having for solving the overall problem are:
(1) 'a' and 'b' need to actually be distinct BroType's. Instead of
'b' being a reference/alias to 'a' with extended attributes, just
create it as it's own BroType by first cloning 'a', then adding any
additional attributes.
(2) BroType could somehow store a mapping of identifier -> attributes
so that on declaring a variable of either 'a' or 'b', we can choose
which attributes apply. But this is relying on the idea that you have
to push the desired attributes into each new Val because you can't
mutate the underlying the BroType since multiple Vals of either type
'a' or 'b' are going to be referencing it.
- Jon
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
