Thanks a bunch for the further context & discussion. The more I've delved into this, the more convinced I've become that we have a basic architectural problem with attributes: they're associated with identifiers and values, but not types ... *except* for hacky ways for records and record fields.
My alternative implementation for type names fares a bit better with the example you gave at http://try.bro.org/#/trybro/saved/275829 ... but still gives counterintuitive behavior when I introduce a minor variant (I'll spare you the details), with the problem being that a subsequent use of &log (rather than the use when a record is declared) isn't propagated to the record's individual fields. I could I guess add code to do that propagation ... but testing further, none of this fixes the original problem that I cared about, which is to be able to declare types with &default values for tables, ala BIT-248: type str_tbl: table[string] of string &default=""; Here the problem is that the only opportunity to associate a &default attribute with a table is when instantiating a table value. It doesn't work if str_tbl is instead used to define a record field, similar to the lack of propagation for &log. I think what we need to do is rethink the basic architecture/structure of attributes. In particular, types in general (not just named types) should be able to have attributes associated with them. The attributes associated with an identifier are those associated with its type plus those directly associated with the identifier (like &redef). While doing this, we can also think about mechanisms for removing attributes. I don't think the "&attr=F" approach mentioned earlier on this thread will do the trick, since it's syntactically/semantically quite weird for attributes that already take expressions as values, such as &default or &read_expire. Vern _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev