----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36462/#review91760 -----------------------------------------------------------
src/tests/mesos.hpp (lines 1328 - 1332) <https://reviews.apache.org/r/36462/#comment145385> Mind referencing the protobuf "union technique" here when mentioning re-use? src/tests/mesos.hpp (line 1418) <https://reviews.apache.org/r/36462/#comment145384> Comparing this with ExpectNoFutureProtobufs, it's a bit confusing that 'T' above represents the message type and 'T' here represents the .type() value to match. Ditto for DropProtobufsType and FutureProtobufType. Perhaps 'Message' and 'UnionType' would be clearer? Also, can we call this ExpectNoFutureUnionProtobuf rather than ExpectNoFutureProtobufsType? The latter is a bit confusing because "type" is overloaded with the type of the protobuf itself. - Ben Mahler On July 13, 2015, 11:57 p.m., Vinod Kone wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36462/ > ----------------------------------------------------------- > > (Updated July 13, 2015, 11:57 p.m.) > > > Review request for mesos and Ben Mahler. > > > Bugs: MESOS-2913 > https://issues.apache.org/jira/browse/MESOS-2913 > > > Repository: mesos > > > Description > ------- > > Needed these abstractions for capturing specific CALLs explicitly in > subsequent reviews. > > > Diffs > ----- > > src/tests/mesos.hpp 9157ac079808d2686592e54ea26a26e6a0825ed3 > > Diff: https://reviews.apache.org/r/36462/diff/ > > > Testing > ------- > > Tested in subsequent reviews. > > > Thanks, > > Vinod Kone > >
