I suspected, that the syntax may raise questions, but some syntax should have been chosen to make a working patch. :) It does not matter much to me, of course it could be changed in the way you prefer to see it your product. Yes, communities are not arrays, but on the other hand positional addressing of fields is also intuitive and understandable, so I do not see it as a big problem. For dot-notation is better to stick with official names, like you suggest. I, personally, would prefer something without subscription signs as they take more time to type :), for example: global, data1, data2. And do you know something suitable for standard communities? The best I can think of is "high" and "low". As for EC communities, I did not even touched them, I do not have experience with them and they look overcomplicated :), but dot-notation I think should be better for them, as it will allow to choose different representations.
On Thu, Dec 16, 2021 at 6:34 PM Ondrej Zajicek <[email protected]> wrote: > > On Thu, Dec 16, 2021 at 02:41:28PM +0100, Alexander Zubkov wrote: > > Hi everyone! > > > > I made a couple of patches to do some interesting stuff with communities. > > The first patch allows to pick a component from a standard or a large > > community: > > > > (10, 20, 30) @ 2 --> 20 > > > > And the second patch allows to search for minimum or maximum element > > in a community list. This combined allows to do some cool stuff with > > communities like this: > > > > bgp_local_pref = filter(bgp_large_community, [(<as>, <localpref_val>, > > *)]).min @ 3 > > > > This will find us the minimum from our "localpref" communities and get > > that number as integer, ready to assign it where we need. Now we use a > > series of if's to check all the possible variants and that is not very > > convenient. I think this features will greatly boost the possibilities > > of working with communities in bird. > > Hi > > Nice patches, thanks! I agree that these features are pretty useful. > Will merge the second one with no comments. > > With the first one, i do not really like the syntax. (Large) communities > are not arrays to access them with indexing operator, and also using '@' > as indexing operator is pretty unortodox. These are regular structures, > so it is natural to use structure field accessors. Question is how these > fields should be named, perhaps: global_id, data_1, data_2? > > That would make: > > (10, 20, 30) . global_id --> 10 > (10, 20, 30) . data_1 --> 20 > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: [email protected]) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so."
