So one thing to keep in mind is that not many people will ever write code using this; it's just for function hooks, and I imagine their use will be limited. I'm personaly still leaning towards the pair, but it's not a big deal, the main point was the pass-by-value, and I'm fine either way. If we stick with the wrapper, we should however at least rename to something more semantically meaninful than ValWrapper, like ValOrNull (better ideas appreciated :).
Gilbert, please reset to merge request once you're done updating the branch. Robin On Fri, Oct 17, 2014 at 19:31 +0000, you wrote: > > On Oct 17, 2014, at 1:34 PM, Gilbert Clark <[email protected]> wrote: > > > To be honest, I'm not sure if expecting a user to return a > > std::pair<bool, Val*> from a plugin function hook is more or less > > obvious than an explicit wrapper. One thing that makes this a little > > less obvious to me is that the usage of this construct won't be limited > > to bro folks reviewing this code: plugin authors will need to craft one > > of these (either ValWrapper or std::pair) and return them from the > > hook. std::pair might actually be a little easier, since that might > > make it more obvious what's happening there (since std::pair is vanilla > > C++) ... but it also might not. > > I think unless the API is designed to be generic, one reason std::pair<T1, > T2> may be less obvious is that if it shows up in multiple places, one > doesn’t really know at a glance that they express the same meaning/intention. > > - Jon > _______________________________________________ > bro-dev mailing list > [email protected] > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -- Robin Sommer * ICSI/LBNL * [email protected] * www.icir.org/robin _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
