-
Key: DDSJAVA-32
-
Legacy Issue Number: 16541
-
Status: closed
-
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
-
Summary:
The org.omg.dds.core.status.Status class currently extends the java.util.EventObject.
The issue I have with this is that a status and an event are to different concepts.
A status represents a continuous value or set of values which are always defined,
while an event represents and happening. For instance an event could be used to notify
the change of status but not the status itself.[Resolution]
That said the refactoring suggested is to re-organize the current status types
so to clearly distinguish what is are statuses and what are the events. As such,
all the status currently defined should remove reference to the source. Why?
Because the statuses are retrieved from the source thus it is kind of silly to
add back the source on the communication status.Let me give you an example ("dr" below is a DataReader):
RequestedDeadlineMissedStatus s = dr.getRequestedDeadlineMissedStatus();
// this give back the reader we already know, thus it is not real useful
// information which should simply be removed.
s.source())BTW the status types as well as the relative accessor methods should
drop the trailing "Status" as it is not so informative.That said, we should add an event type associated to each status defined like this:
class RequestedDeadlineMissedEvent
{ private RequestedDeadlineMissed status; private DataReader source; //... useful methods }The event type is the one that should be used as a parameter of the listener methods.
Finally, it is worth noticing that the suggested refactoring will fix the
DataAvailableStatus anomaly. This type currently defined as a status is actually
an event and as such should be treated. So where is the anomaly, for this status
there are no methods on the data reader and there is really no status information
such as saying... Yes there are 15 new samples or something like this. -
Reported: DDS-Java 1.0b1 — Wed, 7 Sep 2011 04:00 GMT
-
Disposition: Resolved — DDS-Java 1.0b2
-
Disposition Summary:
That said the refactoring suggested is to re-organize the current status types so to clearly distinguish what is are statuses and what are the events. As such, all the status currently defined should remove reference to the source. Why? Because the statuses are retrieved from the source thus it is kind of silly to add back the source on the communication status.
{ private RequestedDeadlineMissed status; private DataReader source; //... useful methods }
Let me give you an example ("dr" below is a DataReader):
RequestedDeadlineMissedStatus s = dr.getRequestedDeadlineMissedStatus();
// this give back the reader we already know, thus it is not real useful
// information which should simply be removed.
s.source())
BTW the status types as well as the relative accessor methods should drop the trailing "Status" as it is not so informative.
That said, we should add an event type associated to each status defined like this:
class RequestedDeadlineMissedEventThe event type is the one that should be used as a parameter of the listener methods.
Finally, it is worth noticing that the suggested refactoring will fix the DataAvailableStatus anomaly. This type, currently defined as a status, is actually an event and as such should be treated. So where is the anomaly, for this status there are no methods on the data reader and there is really no status information such as saying... Yes there are 15 new samples or something like this. -
Updated: Fri, 6 Mar 2015 20:58 GMT
DDSJAVA — A Status is not an Event. An Event is not a Status, it notifies a status change
- Key: DDSJAVA-32
- OMG Task Force: Java 5 Language PSM for DDS 1.0 FTF