> A nice thing about "add" and "delete" for sets is that you can infer the > data type that you're operating on just looking at the local code/line.
Only sort of. For delete, you don't know whether it's a table or a set, and for neither do you know what type of table/set if you can't immediately apprehend the type of the index (e.g., "delete foo[foo2]" doesn't tell me what type of index the set/table foo uses). > E.g. say you come back to some code after a few months and see "foo += > 1". Not obvious what 'foo' is anymore. I don't think it's reasonable to have the bar be "can you tell what's going on in isolation". It should include consideration of associated context, variable names, and comments. In fact, even now you don't know whether for "foo += 1" foo is an integer, a count, or a double. > I do also notice that you had "s + e" in the proposal and not "v + e". > Isn't that weird by the same logic or is it just an accidental omission? This is because "v + e" already has a meaning: apply "+ e" to each element of v. (Note though that "v += e" is not currently allowed.) > v += e Append element to vector > > And for that, a BiF or generic script-layer function call (if that were > possible) would even make me happy: > > push(v, e) > ... > add_to_set(s, v) > delete_from_set(s, v) Yuck. I would hate this. Might as well use Lisp! A basic tenet of Bro's language design has been to minimize verbosity. (For example, its use of type inference, and its support of C-style operators like "++".) Let's please not move in that direction. Vern _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev