Issue 15499: Operation::isConsistentWith (uml2-rtf) Source: (Dr. Maged Elaasar, melaasar(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) Resolution: Revised Text: Actions taken: September 13, 2010: received issue Discussion: End of Annotations:===== ubject: Operation::isConsistentWith To: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 13 Sep 2010 00:05:22 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 09/13/2010 00:05:23 The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged Subject: RE: Operation::isConsistentWith Date: Mon, 13 Sep 2010 09:08:39 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operation::isConsistentWith thread-index: ActS+ebvYGoxuMRSS+mNaTptb/LYLQASsfpw From: "Ed Seidewitz" To: "Maged Elaasar" Cc: Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged Subject: RE: Operation::isConsistentWith To: "Ed Seidewitz" Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 13 Sep 2010 09:53:57 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 09/13/2010 09:53:58 Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged pic03557.gif Subject: RE: Operation::isConsistentWith To: Maged Elaasar Cc: "Ed Seidewitz" , uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Mon, 13 Sep 2010 10:40:48 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 09/13/2010 10:40:49 Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged pic21049.gif From: Steve Cook To: Maged Elaasar CC: Ed Seidewitz , "uml2-rtf@omg.org" Subject: RE: Operation::isConsistentWith Thread-Topic: Operation::isConsistentWith Thread-Index: AQHLUvk0eCEc0yu5dESrFUvdTv30rJMP0tqAgAAMqICAAA0XAIABfMyA Date: Tue, 14 Sep 2010 12:29:37 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.36] This is the old contravariant/covariant parameter type issue. The correct way to resolve it is to identify whether parameters are .in., .out. or both. If both, there can be no change of type; if .in. there can be contravariant change; if .out. there can be covariant change. Eiffel allows covariant change for all parameters and in consequence has holes in its type checking. I think this constraint in UML was written when Eiffel was somewhat fashionable, and all other languages required type equality of parameters for redefinition. The key question here is whether we want UML to be able to create models that round trip with different languages that take different approaches to this problem. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 13 September 2010 07:41 To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged Date: Tue, 14 Sep 2010 09:42:25 -0400 From: "Chonoles, Michael J" Subject: RE: RE: Operation::isConsistentWith To: Steve Cook , Maged Elaasar Cc: Ed Seidewitz , "uml2-rtf@omg.org" Thread-Topic: RE: Operation::isConsistentWith Thread-Index: AQHLUvk0eCEc0yu5dESrFUvdTv30rJMP0tqAgAAMqICAAA0XAIABfMyAgAAGwzA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Yes, to the key question. And I feel sure that it is not .all. other languages. This is still compatible with the stricter Liskov substitution principle (LSP) From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 8:30 AM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: Ex: RE: Operation::isConsistentWith This is the old contravariant/covariant parameter type issue. The correct way to resolve it is to identify whether parameters are .in., .out. or both. If both, there can be no change of type; if .in. there can be contravariant change; if .out. there can be covariant change. Eiffel allows covariant change for all parameters and in consequence has holes in its type checking. I think this constraint in UML was written when Eiffel was somewhat fashionable, and all other languages required type equality of parameters for redefinition. The key question here is whether we want UML to be able to create models that round trip with different languages that take different approaches to this problem. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 13 September 2010 07:41 To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged Subject: RE: Operation::isConsistentWith [Issue 15499] Date: Tue, 14 Sep 2010 09:57:00 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Operation::isConsistentWith [Issue 15499] thread-index: AQHLUvk0eCEc0yu5dESrFUvdTv30rJMP0tqAgAAMqICAAA0XAIABfMyAgAAXjvA= From: "Ed Seidewitz" To: "Steve Cook" Cc: Steve . Bertrand Meyer, of course, had an argument why the covariant constraint was the correct way to do it even for return parameters. But I can.t think of any other language than Eiffel that picked that up. As you say, all the mainstream strongly-typed OO languages require equality of types. Nevertheless, perhaps we do want to keep UML general here. The problem is that this isn.t exactly a .semantic variation point. . it is a key static constraint on the well-formedness of the redefinition of operations. Note that the question is solely on out and return parameters . I think we can agree that the current covariant constraint makes sense for in parameters and that inout parameters should be constrained to have the same type. While it is not particularly elegant, perhaps the most general thing to do is to allow out and return parameters to be either covariant or contravariant. This, at least, establishes that the type of the redefining operation parameter has to be related in one of these ways to the type of the redefined operation parameter. The actual rules for any specific programming language are then further constraints on the ones given in UML. We can even add a note that it is an allowed variation point to place addition constraints on redefinition, such as requiring all parameter types to be equal, or allowing on contravariant or covariant change in the types of out and return parameters. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 8:30 AM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith This is the old contravariant/covariant parameter type issue. The correct way to resolve it is to identify whether parameters are .in., .out. or both. If both, there can be no change of type; if .in. there can be contravariant change; if .out. there can be covariant change. Eiffel allows covariant change for all parameters and in consequence has holes in its type checking. I think this constraint in UML was written when Eiffel was somewhat fashionable, and all other languages required type equality of parameters for redefinition. The key question here is whether we want UML to be able to create models that round trip with different languages that take different approaches to this problem. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 13 September 2010 07:41 To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged Subject: RE: Operation::isConsistentWith [Issue 15499] Date: Tue, 14 Sep 2010 09:59:44 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Operation::isConsistentWith [Issue 15499] thread-index: AQHLUvk0eCEc0yu5dESrFUvdTv30rJMP0tqAgAAMqICAAA0XAIABfMyAgAAXjvCAAAK1IA== From: "Ed Seidewitz" To: "Steve Cook" Cc: Sorry, one change to what I said below: If you allow out and return parameters to be covariant, then you would want to allow inout parameters to be covariant, too. So the general rule is that in and inout parameters are covariant (equal types for inout parameters being a restriction of covariance), while out and return parameters can be either covariant or contravariant. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Tuesday, September 14, 2010 9:57 AM To: 'Steve Cook' Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Steve . Bertrand Meyer, of course, had an argument why the covariant constraint was the correct way to do it even for return parameters. But I can.t think of any other language than Eiffel that picked that up. As you say, all the mainstream strongly-typed OO languages require equality of types. Nevertheless, perhaps we do want to keep UML general here. The problem is that this isn.t exactly a .semantic variation point. . it is a key static constraint on the well-formedness of the redefinition of operations. Note that the question is solely on out and return parameters . I think we can agree that the current covariant constraint makes sense for in parameters and that inout parameters should be constrained to have the same type. While it is not particularly elegant, perhaps the most general thing to do is to allow out and return parameters to be either covariant or contravariant. This, at least, establishes that the type of the redefining operation parameter has to be related in one of these ways to the type of the redefined operation parameter. The actual rules for any specific programming language are then further constraints on the ones given in UML. We can even add a note that it is an allowed variation point to place addition constraints on redefinition, such as requiring all parameter types to be equal, or allowing on contravariant or covariant change in the types of out and return parameters. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 8:30 AM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith This is the old contravariant/covariant parameter type issue. The correct way to resolve it is to identify whether parameters are .in., .out. or both. If both, there can be no change of type; if .in. there can be contravariant change; if .out. there can be covariant change. Eiffel allows covariant change for all parameters and in consequence has holes in its type checking. I think this constraint in UML was written when Eiffel was somewhat fashionable, and all other languages required type equality of parameters for redefinition. The key question here is whether we want UML to be able to create models that round trip with different languages that take different approaches to this problem. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 13 September 2010 07:41 To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged From: Steve Cook To: Ed Seidewitz CC: "uml2-rtf@omg.org" Subject: RE: Operation::isConsistentWith [Issue 15499] Thread-Topic: Operation::isConsistentWith [Issue 15499] Thread-Index: AQHLVBUzZNOA+XpkLUqET3/yQbXG+JMRlplw Date: Tue, 14 Sep 2010 15:16:11 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.36] Ed Isn.t that the wrong way round? Out and return parameters can be covariant. In parameters ought to be contravariant. Inout parameters ought to have no variance and Eiffel allows them to be covariant. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 14 September 2010 07:00 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Sorry, one change to what I said below: If you allow out and return parameters to be covariant, then you would want to allow inout parameters to be covariant, too. So the general rule is that in and inout parameters are covariant (equal types for inout parameters being a restriction of covariance), while out and return parameters can be either covariant or contravariant. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Tuesday, September 14, 2010 9:57 AM To: 'Steve Cook' Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Steve . Bertrand Meyer, of course, had an argument why the covariant constraint was the correct way to do it even for return parameters. But I can.t think of any other language than Eiffel that picked that up. As you say, all the mainstream strongly-typed OO languages require equality of types. Nevertheless, perhaps we do want to keep UML general here. The problem is that this isn.t exactly a .semantic variation point. . it is a key static constraint on the well-formedness of the redefinition of operations. Note that the question is solely on out and return parameters . I think we can agree that the current covariant constraint makes sense for in parameters and that inout parameters should be constrained to have the same type. While it is not particularly elegant, perhaps the most general thing to do is to allow out and return parameters to be either covariant or contravariant. This, at least, establishes that the type of the redefining operation parameter has to be related in one of these ways to the type of the redefined operation parameter. The actual rules for any specific programming language are then further constraints on the ones given in UML. We can even add a note that it is an allowed variation point to place addition constraints on redefinition, such as requiring all parameter types to be equal, or allowing on contravariant or covariant change in the types of out and return parameters. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 8:30 AM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith This is the old contravariant/covariant parameter type issue. The correct way to resolve it is to identify whether parameters are .in., .out. or both. If both, there can be no change of type; if .in. there can be contravariant change; if .out. there can be covariant change. Eiffel allows covariant change for all parameters and in consequence has holes in its type checking. I think this constraint in UML was written when Eiffel was somewhat fashionable, and all other languages required type equality of parameters for redefinition. The key question here is whether we want UML to be able to create models that round trip with different languages that take different approaches to this problem. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 13 September 2010 07:41 To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged Subject: RE: Operation::isConsistentWith [Issue 15499] Date: Tue, 14 Sep 2010 11:28:41 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Operation::isConsistentWith [Issue 15499] thread-index: AQHLVBUzZNOA+XpkLUqET3/yQbXG+JMRlplwgAABphA= From: "Ed Seidewitz" To: "Steve Cook" Cc: Steve . Oops, you are right. I got it backwards. It is always tricky keeping this straight! Sorry, the proposal for UML would be to allow in parameters to be either covariant or contravariant, while out, inout and return parameters must be covariant. Right? This would simply mean weakening the current constraint (which only allows covariance for all directions) to also allow contravariance for in parameters. (By the way, I believe that Meyer.s argument was that generalizing the type of an in parameter of a redefined operation is almost never really useful in practice, while it is sometimes the case that you actually want the redefined operation to only act on a subset of the input values allowed for the redefining operation. Thus it is pragmatically better to accept the weakening of static typing resulting from the covariance of in parameters and to rely instead on dynamic type checking or preconditions. So continuing to allow the option for covariance of in parameters in UML is probably not a bad thing . though, really, just having the same type is satisfactory in most cases.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 11:16 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Ed Isn.t that the wrong way round? Out and return parameters can be covariant. In parameters ought to be contravariant. Inout parameters ought to have no variance and Eiffel allows them to be covariant. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 14 September 2010 07:00 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Sorry, one change to what I said below: If you allow out and return parameters to be covariant, then you would want to allow inout parameters to be covariant, too. So the general rule is that in and inout parameters are covariant (equal types for inout parameters being a restriction of covariance), while out and return parameters can be either covariant or contravariant. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Tuesday, September 14, 2010 9:57 AM To: 'Steve Cook' Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Steve . Bertrand Meyer, of course, had an argument why the covariant constraint was the correct way to do it even for return parameters. But I can.t think of any other language than Eiffel that picked that up. As you say, all the mainstream strongly-typed OO languages require equality of types. Nevertheless, perhaps we do want to keep UML general here. The problem is that this isn.t exactly a .semantic variation point. . it is a key static constraint on the well-formedness of the redefinition of operations. Note that the question is solely on out and return parameters . I think we can agree that the current covariant constraint makes sense for in parameters and that inout parameters should be constrained to have the same type. While it is not particularly elegant, perhaps the most general thing to do is to allow out and return parameters to be either covariant or contravariant. This, at least, establishes that the type of the redefining operation parameter has to be related in one of these ways to the type of the redefined operation parameter. The actual rules for any specific programming language are then further constraints on the ones given in UML. We can even add a note that it is an allowed variation point to place addition constraints on redefinition, such as requiring all parameter types to be equal, or allowing on contravariant or covariant change in the types of out and return parameters. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 8:30 AM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith This is the old contravariant/covariant parameter type issue. The correct way to resolve it is to identify whether parameters are .in., .out. or both. If both, there can be no change of type; if .in. there can be contravariant change; if .out. there can be covariant change. Eiffel allows covariant change for all parameters and in consequence has holes in its type checking. I think this constraint in UML was written when Eiffel was somewhat fashionable, and all other languages required type equality of parameters for redefinition. The key question here is whether we want UML to be able to create models that round trip with different languages that take different approaches to this problem. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 13 September 2010 07:41 To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged From: Steve Cook To: Ed Seidewitz CC: "uml2-rtf@omg.org" Subject: RE: Operation::isConsistentWith [Issue 15499] Thread-Topic: Operation::isConsistentWith [Issue 15499] Thread-Index: AQHLVBUzZNOA+XpkLUqET3/yQbXG+JMRlplwgAABphCAAChAYA== Date: Tue, 14 Sep 2010 17:44:03 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.70] Ed I agree on all points J -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 14 September 2010 08:29 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Steve . Oops, you are right. I got it backwards. It is always tricky keeping this straight! Sorry, the proposal for UML would be to allow in parameters to be either covariant or contravariant, while out, inout and return parameters must be covariant. Right? This would simply mean weakening the current constraint (which only allows covariance for all directions) to also allow contravariance for in parameters. (By the way, I believe that Meyer.s argument was that generalizing the type of an in parameter of a redefined operation is almost never really useful in practice, while it is sometimes the case that you actually want the redefined operation to only act on a subset of the input values allowed for the redefining operation. Thus it is pragmatically better to accept the weakening of static typing resulting from the covariance of in parameters and to rely instead on dynamic type checking or preconditions. So continuing to allow the option for covariance of in parameters in UML is probably not a bad thing . though, really, just having the same type is satisfactory in most cases.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 11:16 AM To: Ed Seidewitz Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Ed Isn.t that the wrong way round? Out and return parameters can be covariant. In parameters ought to be contravariant. Inout parameters ought to have no variance and Eiffel allows them to be covariant. From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 14 September 2010 07:00 To: Steve Cook Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Sorry, one change to what I said below: If you allow out and return parameters to be covariant, then you would want to allow inout parameters to be covariant, too. So the general rule is that in and inout parameters are covariant (equal types for inout parameters being a restriction of covariance), while out and return parameters can be either covariant or contravariant. -- Ed -------------------------------------------------------------------------------- From: Ed Seidewitz Sent: Tuesday, September 14, 2010 9:57 AM To: 'Steve Cook' Cc: uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith [Issue 15499] Steve . Bertrand Meyer, of course, had an argument why the covariant constraint was the correct way to do it even for return parameters. But I can.t think of any other language than Eiffel that picked that up. As you say, all the mainstream strongly-typed OO languages require equality of types. Nevertheless, perhaps we do want to keep UML general here. The problem is that this isn.t exactly a .semantic variation point. . it is a key static constraint on the well-formedness of the redefinition of operations. Note that the question is solely on out and return parameters . I think we can agree that the current covariant constraint makes sense for in parameters and that inout parameters should be constrained to have the same type. While it is not particularly elegant, perhaps the most general thing to do is to allow out and return parameters to be either covariant or contravariant. This, at least, establishes that the type of the redefining operation parameter has to be related in one of these ways to the type of the redefined operation parameter. The actual rules for any specific programming language are then further constraints on the ones given in UML. We can even add a note that it is an allowed variation point to place addition constraints on redefinition, such as requiring all parameter types to be equal, or allowing on contravariant or covariant change in the types of out and return parameters. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Tuesday, September 14, 2010 8:30 AM To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith This is the old contravariant/covariant parameter type issue. The correct way to resolve it is to identify whether parameters are .in., .out. or both. If both, there can be no change of type; if .in. there can be contravariant change; if .out. there can be covariant change. Eiffel allows covariant change for all parameters and in consequence has holes in its type checking. I think this constraint in UML was written when Eiffel was somewhat fashionable, and all other languages required type equality of parameters for redefinition. The key question here is whether we want UML to be able to create models that round trip with different languages that take different approaches to this problem. -- Steve From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: 13 September 2010 07:41 To: Maged Elaasar Cc: Ed Seidewitz; uml2-rtf@omg.org Subject: RE: Operation::isConsistentWith Thinking more about it... The call, as it is known to the client is a call to an instance of X with a parameter instance of A. At runtime, X can be a X or a Y and the parameter can be a A or a B. So we have 4 possible pairs of instance types: (X,A), (X,B), (Y,B), (Y,A). In the first three cases, there is no problem. In the (Y,A) case, will the parent version of the operation be called instead or is it hidden? Maged Elaasar/Ottawa/IBM@IBMCA Maged Elaasar/Ottawa/IBM@IBMCA 09/13/2010 09:53 AM To "Ed Seidewitz" cc uml2-rtf@omg.org Subject RE: Operation::isConsistentWith Ed, Besides the OCL issue, I would like the understand the semantics of operation redefinition more. Is it meant to satisfy the (Liskov) principle of substitution? The current constraint allows the types of all parameters (formal or return result) in a redefining operation to be specializations of the types of formal parameters in a redefined operation.'' Example: if you have Y->X, B->A and N->M redefined: X::O(a : A) : M redefining: Y::O(b : B) : N and you have a call to X::O on an instance of X like this: mmm = xxx.O(aaa) can this call be valid if the instance of X (xxx) was substituted with an instance of Y (yyy): mmm = yyy.O(aaa) I think there will be a problem because it is not safe to coerce the argument (aaa) down to formal parameter of type B. Am I missing something? "Ed Seidewitz" "Ed Seidewitz" 09/13/2010 09:08 AM To Maged Elaasar/Ottawa/IBM@IBMCA cc Subject RE: Operation::isConsistentWith Maged . Yes, I have noticed this before, and I believe the OCL is wrong. Of course, there is lots and lots of incorrect OCL in the spec right now. I hope we can fix it all in UML 2.5. -- Ed -------------------------------------------------------------------------------- From: Maged Elaasar [mailto:melaasar@ca.ibm.com] Sent: Monday, September 13, 2010 12:05 AM To: uml2-rtf@omg.org Subject: Operation::isConsistentWith The description for Operation::isConsistentWith(redefinee : RedefinableElement) suggests that parameter direction should be consistent "A redefining operation is consistent with a redefined operation if it has the same number of formal parameters, the same number of return results, and the type of each formal parameter and return result conforms to the type of the corresponding redefined parameter or return result." However, the OCL provided does not check that the "direction" of parameters is consistent. Operation::isConsistentWith(redefinee: RedefinableElement): Boolean; pre: redefinee.isRedefinitionContextValid(self) result = redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter->size() = op.ownedParameter->size() and Sequence{1..self.ownedParameter->size()}-> forAll(i | op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at(1).type)) an Issue? Maged