Issue 6212: UML 2 Super/pg.78/operation redefinition (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: pg. 78 Operation/Constraints: Operation redefinition is effectively covariant ("return type of redefinition must conform to the original return type"). There is a fierce controversy between covariant and contravariant redefinition. Do we mean to rule out contravariant? I wouldn't think so, as it is the most common. Better eliminate this constraint on types. The whole issue of type conformance requires more care. Resolution: see above Revised Text: Actions taken: September 7, 2003: received issue March 8, 2005: closed issue Discussion: The text quoted in the issue report is misquoted. The actual text is part of a condition, not a categorical assertion of what “must” conform, the complete context is as follows: The problem is with the query name “isConsistentWith” it is too strong, it implies this query provides all the consistency one might need in constructing a properly substitutable hierarchy of behaviored classifiers, and the issue is correct in observing that there are different views on consistency: there is a lot more to it than covariant type conformance. Two solutions seem available. 1. Rename the query to “isCovariantWith” 2. A disclaimer in the text to block this misreading of the query name. We propose taking the second solution. Original Text: The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be logically consistent. Revised Text: The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from ‘isConsistentWith()’, as for example, users may define a query named ‘isContravariantWith()’. End of Annotations:===== To: issues@omg.org Subject: UML 2 Super/pg.78/operation redefinition X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: Branislav Selic Date: Sun, 7 Sep 2003 09:43:27 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/07/2003 09:43:30, Serialize complete at 09/07/2003 09:43:30 Subject: RE: Super FTF telecon on Wed. Aug. 18 Date: Tue, 17 Aug 2004 16:43:42 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Super FTF telecon on Wed. Aug. 18 Thread-Index: AcSEqTAaQMluTGe6QmefADO1NI9UZAAB1OVQ From: "Karl Frank" To: "Branislav Selic" Cc: , X-OriginalArrivalTime: 17 Aug 2004 23:43:43.0973 (UTC) FILETIME=[08329950:01C484B4] 1. 6212 It may be yet another defect if having a query named "isCoConsistentWith" is incompatible with queries of another name defined in another place "isConsistentWith()" . The prepended "co" is supposed to suggest "covariance" as opposed to "contra" in contravariance. Questions: -- argumentative in intent but meant in a collaborative way, my intent is to get a good spec out of this, not win arguments -- a) How can the "same" query be defined in more than one place?. You say "the query is defined in numerous places in the spec". The same query or queries of the same name? If the name is "isConsistentWith", how is that query inconsistent with one named "isCoConsistentWith" ? b) Isn't it a problem to have the word "consistent" used in a way contrary to its accepted meaning OUTSIDE the spec? For Operations, the definition as it stands in the spec is most certainly not what the words "is consistent with " mean. These words have a longer history by orders of magnitude than the few decades computers have been around. c) For us who are used to naming conventions, and have stomached using the word redefinition to include renaming, why is a made up word like "coconsistent" such a problem? 2. 6404 Given that a resolution to 6404 is in ballot 23, we should surely pull it from Ballot 24. You just sent me a list in which you listed 6405 as one of my remaining 10 issues and I screwed up by pulling 6404. Sorry.. 3. 6437. I always forget about Infra, since I am not on the Infra FTF. Will research the infra implications. 4. 6616 I specifically called Guus' attention to this already in the email you received, don't understand why you should suggest what I have already told you I did. Guus' views on the matter will get good attention, I am sure. But if he wants "isRoot" back (the issue does NOT say it is needed, nor does it give any argument for why it's loss is regrettable) he should explain why, because it is easier to leave it out. It is not in the FAS as approved, and no-one (including Guus) has so far given any complaint. 5. 7400. Yes, the terminology should be "Closed, no change". I had to create my own format for these, reliving the hell you have been thru often enough, because the styles and wording on the issues website do not match our report styles and wording, and I got this wrong. Will change it for the ballot. - Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 6:26 PM To: Karl Frank Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 Karl, some feedback on your propsoed resolutions: 6212: I have two objections to your resolution: (1) I do not feel that renaming "isConsistentWith()" to "isCoConsistentWith()" improves anything as the concept of "co-consistency" is not a common and well-understood term in the computing science community and (2), that query is defined in numerous places in the spec and would have to be redefined everywhere. I would much prefer your second potential solution. 6404: I have already provided a resolution to this issue in ballot 23. (Also, I think that your resolution is incorrect.) 6437: shouldn't this also have an Infrastructure fix in it? 6630: We had this discussion already and I strongly object to your resolution. Specifically, I believe that a client of a dependency should be able to navigate to its dependencies (it is the client). The ramifications of your change are significant since Dependency is the parent class of Realization, Usage, and InterfaceRealization, which are extensively used in many models. Your resolution will impact many implementations adversely. 6616: I seem to recall that Guus felt rather strongly about this one. I suggest that you consult him about it directly. 7400: shouldn't this be a "closed, no change" rather than a "resolved"? Cheers, Bran "Karl Frank" 08/17/2004 03:53 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Super FTF telecon on Wed. Aug. 18 Eight proposals are attached. One, 6630, met with counterarguments in an earlier circulation. I am still convinced my proposal is in the best interest of UML modeling, so I am sending it out again with a little more argument to back it up. The obvious easy resolution is self-evident, just x-out the navigability from Supplier, but before I fall back to that easy answer, I want to try out my preferred solution first. Guus, one of your issues is in this batch, so you should look for it. 6616, humorously but accurately named "isRoot disappeared". Karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 17, 2004 3:20 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Super FTF telecon on Wed. Aug. 18 DATE: Wed. Aug. 18 TIME: 11 am EDT (usual time) DURATION: 35 minutes NUMBER: 866 842-3549 (toll free North America) 1+613 787-5018 (International) PASSCODE: 8455752# Please plan to attend this one, it is very important. Thanks...Bran[attachment "ForBallot24.doc" deleted by Branislav Selic/Ottawa/IBM] To: "Karl Frank" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Super FTF telecon on Wed. Aug. 18 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 17 Aug 2004 20:32:01 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/17/2004 20:32:02, Serialize complete at 08/17/2004 20:32:02 Karl, A few additional comments embedded below: > 1. 6212 It may be yet another defect if having a query named > "isCoConsistentWith" is incompatible with queries of another name > defined in another place "isConsistentWith()" . > The prepended "co" > is supposed to suggest "covariance" as opposed to "contra" in > contravariance. > Questions: -- argumentative in intent but meant in a collaborative > way, my intent is to get a good spec out of this, not win arguments -- > a) How can the "same" query be defined in more than one place?. You > say "the query is defined in numerous places in the spec". The same > query or queries of the same name? If the name is > "isConsistentWith", how is that query inconsistent with one named > "isCoConsistentWith" ? This was by intent. Since "consistency" has different meanings in different contexts and is also a semantic variation point, there is a default version (the one that you renamed) that was intended to be overridden by other more specific versions. So, a change in one place would require the thing to be changed in all the places. > b) Isn't it a problem to have the word "consistent" used in a way > contrary to its accepted meaning OUTSIDE the spec? For Operations, > the definition as it stands in the spec is most certainly not what > the words "is consistent with " mean. These words have a longer > history by orders of magnitude than the few decades computers have > been around. > c) For us who are used to naming conventions, and have stomached > using the word redefinition to include renaming, why is a made up > word like "coconsistent" such a problem? Perhaps you are used to it, but I am not and I honestly don't believe that most people would get any additional information out of it. In fact, I suspect that it will actually raise more questions. That is, while most people have an intuitive understanding of "consitent", I doubt if they have an intuition about what "co-consistent" could mean. > 2. 6404 Given that a resolution to 6404 is in ballot 23, we should > surely pull it from Ballot 24. You just sent me a list in which you > listed 6405 as one of my remaining 10 issues and I screwed up by > pulling 6404. Sorry.. No problem. > 3. 6437. I always forget about Infra, since I am not on the Infra > FTF. Will research the infra implications. OK > 4. 6616 I specifically called Guus' attention to this already in > the email you received, don't understand why you should suggest what > I have already told you I did. Guus' views on the matter will get > good attention, I am sure. But if he wants "isRoot" back (the issue > does NOT say it is needed, nor does it give any argument for why > it's loss is regrettable) he should explain why, because it is > easier to leave it out. It is not in the FAS as approved, and no- > one (including Guus) has so far given any complaint. Sorry. I now recall that you did draw Guus' attention to it. So, this is good. I agree with your proposed resolution, but wanted to make sure that it went into the ballot without being contested. > 5. 7400. Yes, the terminology should be "Closed, no change". I had > to create my own format for these, reliving the hell you have been > thru often enough, because the styles and wording on the issues > website do not match our report styles and wording, and I got this > wrong. Will change it for the ballot. No problem. You should be able to get the correct styles if you use the posted Draft FTF report. (And, you are right: I had to manually change the formatting of each and every paragraph of the 890 issues that are in that report.) Regards...Bran pg. 78 Operation/Constraints: Operation redefinition is effectively covariant ("return type of redefinition must conform to the original return type"). There is a fierce controversy between covariant and contravariant redefinition. Do we mean to rule out contravariant? I wouldn't think so, as it is the most common. Better eliminate this constraint on types. The whole issue of type conformance requires more care.