Issue 15967: factory methods on the "parents" (e.g. create_topic, create_data_writer, etc.) (dds-psm-cxx-ftf) Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com) Nature: Uncategorized Issue Severity: Summary: The changes introduced in the final submission to support factory methods on the "parents" (e.g. create_topic, create_data_writer, etc.) has introduced a few issues. a. Reference types are not created in a uniform way. In essence, DomainParticipant, Subscriber, Publisher, DataReader and DataWriter types are instantiated using a different syntax than that used by WaitSets or Conditions. This is unfortunate as it reduces the consistency of the API. b. To eliminate the circular dependencies induced by the factory methods the API has to implement a few "creative" solutions that impact clarity as well as robustness. All of a sudden it is relatively hard to find where is defined what and also the include systems is very fragile, e.g. one can break the API very easily by mistakenly changing one include order. The changes suggested to the submission is to equip each Reference type with a factory method called "create". This not only allows to remove circular references, but it also allows for an organization of the API that is more robust and easier to follow. Furthermore, it ensures that all references are created in an uniform manner. Resolution: Revised Text: Actions taken: January 17, 2011: received issue Discussion: End of Annotations:===== te: Mon, 17 Jan 2011 12:15:47 +0100 From: Angelo Corsaro User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101218 Thunderbird/3.1.7 To: Juergen Boldt , DDS-PSM-Cxx FTF Subject: ISSUE: DDS-PSM-Cxx Dear All, Below the description of an issue on the DDS-PSM-Cxx. ============================================================================= The changes introduced in the final submission to support factory methods on the "parents" (e.g. create_topic, create_data_writer, etc.) has introduced a few issues. a. Reference types are not created in a uniform way. In essence, DomainParticipant, Subscriber, Publisher, DataReader and DataWriter types are instantiated using a different syntax than that used by WaitSets or Conditions. This is unfortunate as it reduces the consistency of the API. b. To eliminate the circular dependencies induced by the factory methods the API has to implement a few "creative" solutions that impact clarity as well as robustness. All of a sudden it is relatively hard to find where is defined what and also the include systems is very fragile, e.g. one can break the API very easily by mistakenly changing one include order. The changes suggested to the submission is to equip each Reference type with a factory method called "create". This not only allows to remove circular references, but it also allows for an organization of the API that is more robust and easier to follow. Furthermore, it ensures that all references are created in an uniform manner. ============================================================================= Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 --------------------------------------------------------------------------------------------------------------------------------------- http://twitter.com/acorsaro | http://opensplice.blogspot.com | http://slideshare.net/angelo.corsaro --------------------------------------------------------------------------------------------------------------------------------------- From: Richard Warren To: Angelo Corsaro CC: "dds-psm-cxx-ftf@omg.org" Date: Thu, 20 Jan 2011 11:08:31 -0800 Subject: Re: issue 15967 -- ISO/IEC C++ DDS PSM FTF issue Thread-Topic: issue 15967 -- ISO/IEC C++ DDS PSM FTF issue Thread-Index: Acu41W32GwPGy7L4TA+ZiF4OMohiBA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p0KJ8VIb021451 Hi, A process suggestion: it would be helpful to associate repository revision numbers with each issue reports to make it easier for people to evaluate specific proposed changes. I plan to do this in the Java PSM FTF as well. >> a. Reference types are not created in a uniform way. In essence, >> DomainParticipant, Subscriber, Publisher, DataReader and DataWriter >> types are instantiated using a different syntax than that used by >> WaitSets or Conditions. This is unfortunate as it reduces the >> consistency of the API. I disagree with this statement. Instances of reference types are created by the classes that own those instances. For example, publishers create writers (exactly as in the other PSMs). WaitSets don't have an owner, so the WaitSet class creates its own instances. This is a consistent methodology. To the extent that this methodology results in syntactic differences among classes, those differences in syntax directly reflect more basic differences is use and semantics. >> b. To eliminate the circular dependencies induced by the factory methods >> the API has to implement a few "creative" solutions that impact >> clarity as well as robustness. All of a sudden it is relatively hard >> to find where is defined what and also the include systems is very >> fragile, e.g. one can break the API very easily by mistakenly changing >> one include order. If the compilation can be broken by changing the order of includes, then it sounds like one of those included files does not have the correct set of dependencies declared in it. If so, that's a bug that should be tracked down and fixed. I see it as independent of the design pattern we use. The circular dependencies come from the PIM, and this PSM has a consistent methodology to break those dependencies structurally without breaking them semantically: 1. Distinguish name dependencies from definition dependencies with forward declarations. This is a conventional practice from the standard library that improves compile times as well as limiting dependencies; see . 2. Eliminate definition dependencies from the public API by refactoring child-to-parent navigation methods to top-level functions. (Angelo, it looks like you are proposing to undo this refactoring from the code sample you sent me.) 3. Eliminate definition dependencies from the internal implementation. How this is done is not normative and will vary by implementation. The reference implementation uses "Holder" classes that use pointers to change definition dependencies into name dependencies. Another possibility would be to use a centralized registry. Which of these measures is/are you concerned about with respect to clarity and robustness? Thanks, - Rick -- Rick Warren Principal Engineer RTI Tel 408.990.7455 rick.warren@rti.com www.rti.com RTI - The Global Leader in DDS Date: Fri, 21 Jan 2011 11:22:02 +0100 From: Angelo Corsaro Organization: PrismTech User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 To: Richard Warren CC: "dds-psm-cxx-ftf@omg.org" Subject: Re: issue 15967 -- ISO/IEC C++ DDS PSM FTF issue Hello `, On 20.1.11 8:08 PM, Richard Warren wrote: Hi, A process suggestion: it would be helpful to associate repository revision numbers with each issue reports to make it easier for people to evaluate specific proposed changes. I plan to do this in the Java PSM FTF as well. For the time being I am running a branch for the FTF. a. Reference types are not created in a uniform way. In essence, DomainParticipant, Subscriber, Publisher, DataReader and DataWriter types are instantiated using a different syntax than that used by WaitSets or Conditions. This is unfortunate as it reduces the consistency of the API. I disagree with this statement. Instances of reference types are created by the classes that own those instances. For example, publishers create writers (exactly as in the other PSMs). WaitSets don't have an owner, so the WaitSet class creates its own instances. This is a consistent methodology. To the extent that this methodology results in syntactic differences among classes, those differences in syntax directly reflect more basic differences is use and semantics. On this we seem to disagree. For me there should be just one way of creating a reference types which is uniform regardless of whether the reference type has a relationship with another type (e.g. parent entity) or not. Having different ways of creating a reference types depending on whether it is associated with another object or not clutters the API -- IM(H)O. b. To eliminate the circular dependencies induced by the factory methods the API has to implement a few "creative" solutions that impact clarity as well as robustness. All of a sudden it is relatively hard to find where is defined what and also the include systems is very fragile, e.g. one can break the API very easily by mistakenly changing one include order. If the compilation can be broken by changing the order of includes, then it sounds like one of those included files does not have the correct set of dependencies declared in it. If so, that's a bug that should be tracked down and fixed. I see it as independent of the design pattern we use. The circular dependencies come from the PIM, and this PSM has a consistent methodology to break those dependencies structurally without breaking them semantically: 1. Distinguish name dependencies from definition dependencies with forward declarations. This is a conventional practice from the standard library that improves compile times as well as limiting dependencies; see . 2. Eliminate definition dependencies from the public API by refactoring child-to-parent navigation methods to top-level functions. (Angelo, it looks like you are proposing to undo this refactoring from the code sample you sent me.) 3. Eliminate definition dependencies from the internal implementation. How this is done is not normative and will vary by implementation. The reference implementation uses "Holder" classes that use pointers to change definition dependencies into name dependencies. Another possibility would be to use a centralized registry. Which of these measures is/are you concerned about with respect to clarity and robustness? I don't like massive forward declarations as you are forced to pull in more definitions that you might need. On top of that the re-factoring I did removes all the need for using holder types in the delegate layer. Anyway, my suggestion is to wait few days for the proposed update and then have all of the FTF members comment. Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 | twitter.com/acorsaro | slideshare.net/angelo.corsaro |