[Bro-Dev] Rethinking Broker's blocking API
Matthias Vallentin
vallentin at icir.org
Mon Jan 9 11:34:23 PST 2017
> But not a big deal either way, any of these options sounds fine to me.
This is the synopsis for the slightly adapted message class, no other
changes:
class message {
public:
/// Checks whether a message is a (topic, data) pair.
/// @returns `true` iff the message contains a (topic, data) pair.
explicit operator bool() const;
/// @returns the contained topic.
/// @pre `static_cast<bool>(*this)`
const broker::topic& topic() const;
/// @returns the contained topic.
/// @pre `static_cast<bool>(*this)`
const broker::data& data() const;
/// @returns the contained status.
/// @pre `!*this`
const broker::status& status() const;
};
I opted against a .failed() member in broker::message, because it's up
to the concrete status instance to define failure or a mere status
change. A message is now either a (topic, data) pair or a status
instance.
To distinguish between the two status, I use operator bool. Since this
is almost the same as a failed() method, I have one last idea: instead
of returning const-references to topic, data, and instances. We could
simply return non-owning const-pointers, which are non-null if and only
if the respective type is active:
if (auto data = msg.data())
f(*data)
else
g(*msg.status())
I've also updated how to do status/error handling. See the documentation
at http://bro.github.io/broker/comm.html#status-and-error-handling for
details.
Matthias
More information about the bro-dev
mailing list