DDSPSMC11_ — Condition classes should only be used with WaitSets

The DataReader API provides methods to read samples with a condition. This condition can be either a ReadCondition or a QueryCondition, and in this case the samples returned are either filtered by the status (ReadCondition) or the content+status (QueryCondition).
The ReadCondition is completely in overlap with the instance/status/view states and its use is really irrelevant when in combination with the DataReader. On the other end the only aspect of the QueryCondition that really matters to a DataReader are the query expression and parameters.

By looking carefully at the API, it seems apparent that the ReadCondition and the QueryCondition really make sense only when used with a WaitSet. On the other end, their use in conjunction of a DataReader is a stretch and breaks the semantics of the "Condition". On principle a condition is used to "wait" for a particular status to be true, yet the DataReader "read" are – rightfully – always non-blocking. In addition, the API opens up for gratuitous runtime errors as I could write silly code as follows (in C++):

auto rc = reader.create_readcondition();
reader2.read(..., rc,...);

This although silly is allowed by the API and on a proper DDS implementation should raise an exception.

The same could happen with a QueryCondition!

Resolution
---------------
Limit the use of Read/QueryCondition to waitsets and put in place a more robust mechanism to do status and content filtering on a data-reader read.

An example of what could be done is provided below, where I assume that the DataStatus is the former ReaderState:

reader
.filter_status(DataStatus::new_data())
.filter_content(Query("x < 100 AND y < 100"))
.read();

Equally, one could write (again legal C++ below with little magic under-cover) :

reader
.instance(handle)
.filter_status(DataStatus::new_data())
.filter_content(Query("x < 100 AND y < 100"))
.read();

Notice that this code, not only is very declarative and thus shows very clearly the intent of the programmer, but in addition does not allow for the silly mistakes shown above. Further more, it really highlights he role of the Sample/Instance/View status as a "filter" on the status of data.