DDSJAVA — Improve polymorphic sample creation

Source:

RTI (Rick Warren, rick.warren@rti.com)

Summary:

The specification does not provide a simple, portable way to create a new data sample to use with the middleware. Instead, there are several partial solutions:

· Instantiate a concrete sample type directly: “new Foo()”. This approach doesn’t work in generic methods—i.e. when the concrete type is not statically known. It also doesn’t work with DynamicData.

· Instantiate DynamicData from DynamicDataFactory. But samples of statically known, user-defined types don’t have a “data factory”.

· Use DataReader.createData(). But there is not equivalent on the publishing side.

There should be a single way that works uniformly and generically.

Proposed Resolution:

The proposed resolution has several parts:

1. Introduce a new factory instance method to the TypeSupport class: TypeSupport.newData(). The name of this method is parallel to that of other value type “constructor-like” factories.

2. Support navigation from the TopicDescription to the TypeSupport. Add a new method TopicDescription.getTypeSupport().

3. Simplify the number of ways to get from the data type’s TypeSupport to its Class. Add a method TypeSupport.getType(). Remove the existing methods TopicDescription.getType(), DataWriter.getType(), and DataReader.getType(): they are redundant.

4. Remove the existing method DataReader.createData() and the existing class DynamicDataFactory. They are not needed.

There will therefore be a single polymorphic and generic way to instantiate a sample of any type: by using its TypeSupport. (You can get the TypeSupport from any related TopicDescription, or transitively any DataReader or DataWriter.)

Likewise, there will be a single polymorphic and generic way to get the Class object for any data type: from its TypeSupport. As described in the previous paragraph, you can get to the TypeSupport from a variety of places.

The proposed resolution has several parts:
1. Introduce a new factory instance method to the TypeSupport class: TypeSupport.newData(). The name of this method is parallel to that of other value type “constructor-like” factories.
2. Support navigation from the TopicDescription to the TypeSupport. Add a new method TopicDescription.getTypeSupport().
3. Simplify the number of ways to get from the data type’s TypeSupport to its Class. Add a method TypeSupport.getType(). Remove the existing methods TopicDescription.getType(), DataWriter.getType(), and DataReader.getType(): they are redundant.
4. Remove the existing method DataReader.createData() and the existing class DynamicDataFactory. They are not needed. In the specification document, rename section 7.7.1.1, “DynamicTypeFactory and DynamicDataFactory Interfaces”, to “DynamicTypeFactory Interface”. In the single paragraph of that section, make the word “factories” singular.
See revision #123, which includes the above changes: http://code.google.com/p/datadistrib4j/source/detail?r=123.
5. Remove the factory methods on the built-in topic data classes. Objects of these types can be constructed like those of any other sample type. See also revision #137, which includes this change: http://code.google.com/p/datadistrib4j/source/detail?r=137.
There will therefore be a single polymorphic and generic way to instantiate a sample of any type: by using its TypeSupport. You can get the TypeSupport from any related TopicDescription, or transitively any DataReader or DataWriter.
Likewise, there will be a single polymorphic and generic way to get the Class object for any data type: from its TypeSupport. As described in the previous paragraph, you can get to the TypeSupport from a variety of plac