Issue 18759: UML: Parameter Direction and Effect (uml25-ftf) Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org) Nature: Uncategorized Issue Severity: Summary: The rules on Parameter Direction and Effect, seem overly weak. It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in" It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out" And Conrad says: Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility. But Ed Seidewitz says The object passed out in on inout parameter doesn't have to be the same one that was passed in. For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object. The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out. Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter So, we have at least different suggestions for changes to this material. Resolution: Revised Text: Actions taken: June 5, 2013: received issue Discussion: End of Annotations:===== m: "Chonoles, Michael J" To: "issues@omg.org" , "uml25-ftf@omg.org" Subject: UML: Parameter Direction and Effect. Thread-Topic: UML: Parameter Direction and Effect. Thread-Index: Ac5iIyVTgXLMzpowTt682MW/6Nr1Wg== Date: Wed, 5 Jun 2013 19:30:39 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-05_08:2013-06-05,2013-06-05,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org The rules on Parameter Direction and Effect, seem overly weak. It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in" It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out" And Conrad says: Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility. But Ed Seidewitz says The object passed out in on inout parameter doesn't have to be the same one that was passed in. For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object. The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out. Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter So, we have at least different suggestions for changes to this material. Michael From: "Bock, Conrad" To: "issues@omg.org" , "uml25-ftf@omg.org" Date: Thu, 6 Jun 2013 08:35:17 -0400 Subject: RE: issue 18759 -- UML 2.5 FTF issue Thread-Topic: issue 18759 -- UML 2.5 FTF issue Thread-Index: Ac5iJ0PsrteJb4cWTFChoLeAgjy4hwAitcYg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r56CZLgk010756 Content-Transfer-Encoding: 8bit Juergen, This wasn't intended as an issue. Michael was just highlighting a difference between Ed and my email, but I was sending another at the same time saying I agreed with Ed. Conrad To: "issues@omg.org" , "uml25-ftf@omg.org" Subject: UML: Parameter Direction and Effect. Thread-Topic: UML: Parameter Direction and Effect. Thread-Index: Ac5iIyVTgXLMzpowTt682MW/6Nr1Wg== Date: Wed, 5 Jun 2013 19:30:39 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [158.186.156.82] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-06-05_08:2013-06-05,2013-06-05,1970-01-01 signatures=0 X-Virus-Scanned: amavisd-new at omg.org The rules on Parameter Direction and Effect, seem overly weak. It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in" It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out" And Conrad says: Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility. But Ed Seidewitz says The object passed out in on inout parameter doesn't have to be the same one that was passed in. For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object. The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out. Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter So, we have at least different suggestions for changes to this material. Michael From: "Bock, Conrad" To: "Chonoles, Michael J" , "issues@omg.org" , "uml25-ftf@omg.org" Date: Thu, 6 Jun 2013 08:33:51 -0400 Subject: RE: Parameter Direction and Effect. Thread-Topic: Parameter Direction and Effect. Thread-Index: Ac5iIyVTgXLMzpowTt682MW/6Nr1WgAjslfQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r56CXwFL010354 Michael, > So, we have at least different suggestions for changes to this material. Our emails crossed, there's no disagreement, I agree with Ed. Conrad