Issue 5972: OCL 2: Can collections contain void/undefined objects (ocl2-ftf) Source: Kestral Computing (Mr. Grahame Grieve, grahameg@gmail.com) Nature: Uncategorized Issue Severity: Summary: Is it possible for collections to contain void (= undefined objects)? Conceptually, this would appear to be required so that you can specify whether an item in a collection can be null in an actual implementation. The use of void and undefined() is advised in exactly the same situation in a non-collection context. However, this quote from Section 2.4.11: "In general, an expression where one of the parts is undefined will itself be undefined", along with the rest of the section, shows that you can't use void as a parameter to the collection calls, and in the context of OCL as a language, this makes sense. So I thank that this constraint: context Collection inv: self->forAll(not OclIsUndefined()) is required, and this should be stated to clear up uncertainties. This leaves the problem of how to say whether an "item in a collection can be null in an actual implementation" is inresolvable in OCL 2. Resolution: Revised Text: Revised Text: 1) In section 8.2.2 (Well formedness Rules for the Types Package) add the following constraint:[2] A Collection cannot contain OclInvalid values. context Collection inv: self->forAll(not oclIsInvalid()) 2) In section 8.2 adds a description for the class InvalidType, with the following text: InvalidType represents a type that conforms to all types. The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one instance called OclInvalid. Also update figure 5 adding the InvalidType metaclass in the type inheritance: VoidType DataType Class TupleType SetTypOrderedSetType SequenceType BagType e Type CollectionType 1 * +elementType PrimitiveType InvalidType AnyType Operation Signal MessageType 0..1 * +referredOperation 0..1 * +referredSignal TypeType ElementType 3) In section 8.2.1 (Type Conformance), add the compliance rule for InvalidType with the following text: InvalidType Invalid conforms to all other types [1] context InvalidType inv: Classifier.allInstances()->forAll (c | self.conformsTo (c)) 4) In section 8.3, within the description of VoidType, replace the last sentence by: Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections. 5) Change the title of section 11.2 as follows: """ The OclAny, OclVoid, OclInvalid and OclMessage types."""6) In section 11.2.3 replace "It has a single instance called OclUndefined …" by "It has a single instance called null which corresponds with the UML NullLiteral specification value." Also replace "Any propertycall applied on OclUndefined …" by "Any propertycall applied on null results in OclInvalid". And finally replace: "an instance of the metatype Classifier" by "an instance of the metatype VoidType". 7) In section 11.2 add OclInvalid description with the following text: OclInvalid The type OclInvalid is a type that conforms to all other types. It has one single instance called invalid. Any propertycall applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid(). OclInvalid is itself an instance of the metatype InvalidType 8) In section 11.2.4, change the definition of oclIsUndefined() as follows: Evaluates to true if the self is equal to OclInvalid or to null. post: result = self.isTypeOf( OclVoid) or self.isTypeOf( OclInvalid ). 9) In section 11.2.4, add the definition of iclIsInvalid() as follows: Evaluates to true if the self is equal to OclInvalid. post: result = self.isTypeOf( OclInvalid). 10) Remove 11.2.5 section (definition of OclVoid::oclIsUndefined and badly placed constraint ) – since this method is already defined for AnyType. 11) Add in figure 10 (Abstract syntax metamodel for Literal expression) the metaclasses NullLiteralExp and InvalidLiteralExp. IntegerLiteralExp integerSymbol : Integer RealLiteralExp realSymbol : Real BooleanLiteralExp booleanSymbol : Boolean StringLiteralExp stringSymbol : String UnlimitedNaturalExp symbol : UnlimitedNatural LiteralExp EnumerationLiteral EnumLiteralExp 0..1 * +referredEnumLiteral +literalExp PrimitiveLiteralExp NumericLiteralExp NullLiteralExp InvalidLiteralExp Actions taken: April 22, 2003: received issue Disposition: Resolved Document ptc/2005-06-05 Page 24 Actions taken: April 22, 2003: received issue November 1, 2005: closed issue Discussion: Resolution: The notion of OclUndefined is splitted into two notions: LiteralNull and OclInvalid to distinguish between the situations where we have an absence of value (LiteralNull) and an invalid events (such as division of zero). Collection can contain null values but cannot contain Oclinvalid values. Apart from making more flexible the usage of OCL as a query language, this resolution aligns OCL with UML2 in which the "absence of value" is already modeled by the notion of null literal which is not considered being an invalid value. End of Annotations:===== X-Sender: grahame@mail.kestral.com.au X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 22 Apr 2003 10:22:22 +1000 To: issues@omg.org From: Grahame Grieve Subject: OCL 2: Can collections contain void/undefined objects Cc: healthcare@omg.org Is it possible for collections to contain void (= undefined objects)? Conceptually, this would appear to be required so that you can specify whether an item in a collection can be null in an actual implementation. The use of void and undefined() is advised in exactly the same situation in a non-collection context. However, this quote from Section 2.4.11: "In general, an expression where one of the parts is undefined will itself be undefined", along with the rest of the section, shows that you can't use void as a parameter to the collection calls, and in the context of OCL as a language, this makes sense. So I thank that this constraint: context Collection inv: self->forAll(not OclIsUndefined()) is required, and this should be stated to clear up uncertainties. This leaves the problem of how to say whether an "item in a collection can be null in an actual implementation" is inresolvable in OCL 2. Grahame Subject: OCL-FTF: Question about issues 5970 and 5972 Date: Mon, 16 May 2005 19:22:17 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCL-FTF: Question about issues 5970 and 5972 Thread-Index: AcVaO88bBhYOMteXTW2BZ8hRuLwvvQ== From: "BELAUNDE Mariano RD-MAPS-LAN" To: Cc: "Jos Warmer" X-OriginalArrivalTime: 16 May 2005 17:22:20.0883 (UTC) FILETIME=[D12C2A30:01C55A3B] Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? Regards, Mariano X-Sender: klas0@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 16 May 2005 20:50:37 +0200 To: "BELAUNDE Mariano RD-MAPS-LAN" From: Jos Warmer Subject: Re: OCL-FTF: Question about issues 5970 and 5972 Cc: X-Virus-Scanned: by XS4ALL Virus Scanner Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: RE: OCL-FTF: Question about issues 5970 and 5972 Date: Tue, 17 May 2005 10:50:07 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCL-FTF: Question about issues 5970 and 5972 Thread-Index: AcVaR855EW3VxNBPRXCP+yeiu/AKMQAc7yHA From: "Anders Ivner" To: "Jos Warmer" , "BELAUNDE Mariano RD-MAPS-LAN" Cc: X-OriginalArrivalTime: 17 May 2005 08:50:14.0558 (UTC) FILETIME=[7144CBE0:01C55ABD] Hi all, I agree with Jos on both issues, and would like to add the following wrt the second issue. If the type of defaultValue is a type that has null in the set of possible values, e.g. NullableInteger, then that null value != OclUndefined and therefore collect(defaultValue) is going to return a collection which could possibly contain that null value. /Anders -----Original Message----- From: Jos Warmer [mailto:J.Warmer@klasse.nl] Sent: den 16 maj 2005 20:51 To: BELAUNDE Mariano RD-MAPS-LAN Cc: ocl2-ftf@omg.org Subject: Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: OCL-FTF: OclUndefined versus null literal (issue 5972) Date: Tue, 17 May 2005 18:10:17 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCL-FTF: OclUndefined versus null literal (issue 5972) Thread-Index: AcVaR8jQJlTAAdz5RfGLEdY40oAVegAbwu6w From: "BELAUNDE Mariano RD-MAPS-LAN" To: "Jos Warmer" Cc: X-OriginalArrivalTime: 17 May 2005 16:10:19.0752 (UTC) FILETIME=[EBFDA680:01C55AFA] Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl X-Sender: klas0@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 17 May 2005 21:41:08 +0200 To: "BELAUNDE Mariano RD-MAPS-LAN" From: Jos Warmer Subject: Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Cc: X-Virus-Scanned: by XS4ALL Virus Scanner Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl To: Jos Warmer Cc: "BELAUNDE Mariano RD-MAPS-LAN" , ocl2-ftf@omg.org Subject: Re: OCL-FTF: OclUndefined versus null literal (issue 5972) X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 17 May 2005 23:32:00 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.53HF247 | January 6, 2005) at 05/17/2005 23:32:52, Serialize complete at 05/17/2005 23:32:52 I second Jos opinion. To me, "null" connotes emptiness -- a well-defined notion. OTOH, "undefined" implies that something has not been fully defined. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Jos Warmer 05/17/2005 03:41 PM To "BELAUNDE Mariano RD-MAPS-LAN" cc Subject Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Date: Wed, 18 May 2005 09:14:44 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCL-FTF: OclUndefined versus null literal (issue 5972) Thread-Index: AcVbWkotPdW5RdBTQ2GgnH04qL7XFQAGkBtg From: "BELAUNDE Mariano RD-MAPS-LAN" To: "Branislav Selic" , "Jos Warmer" Cc: X-OriginalArrivalTime: 18 May 2005 07:14:57.0082 (UTC) FILETIME=[4BCCF1A0:01C55B79] Jos and Bran, You are certainly right to want to maintain the distinction between these two concepts. Division by zero fits typically in the invalid category and cannot be considered being an ordinary 'null' value. So following Jos suggestion for the second option, I propose to write a resolution text that will keep the distinction by adding - instead of replacing - the missing 'null' notion (which has to be taken from UML). For compatibility, since up to now, OCL writers have used oclIsUndefined() for both situations (real invalid values and 'null'), I suggest to introduce a new operation called oclIsInvalid(). The operation oclIsUndefined() will return true in both cases (invalid values and null values) whereas oclIsInvalid() will return true only for invalid values (values that are equal to the OclInvalid runtime singleton). -Mariano -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 18 mai 2005 05:32 À : Jos Warmer Cc : BELAUNDE Mariano RD-MAPS-LAN; ocl2-ftf@omg.org Objet : Re: OCL-FTF: OclUndefined versus null literal (issue 5972) I second Jos opinion. To me, "null" connotes emptiness -- a well-defined notion. OTOH, "undefined" implies that something has not been fully defined. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Jos Warmer 05/17/2005 03:41 PM To "BELAUNDE Mariano RD-MAPS-LAN" cc Subject Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: RE: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Date: Thu, 19 May 2005 10:48:14 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Thread-Index: AcVbWkotPdW5RdBTQ2GgnH04qL7XFQAGkBtgADYsz4A= From: "Anders Ivner" To: "BELAUNDE Mariano RD-MAPS-LAN" , "Branislav Selic" , "Jos Warmer" Cc: X-OriginalArrivalTime: 19 May 2005 08:48:18.0288 (UTC) FILETIME=[80CAE700:01C55C4F] Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 18 maj 2005 09:15 To: Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Jos and Bran, You are certainly right to want to maintain the distinction between these two concepts. Division by zero fits typically in the invalid category and cannot be considered being an ordinary 'null' value. So following Jos suggestion for the second option, I propose to write a resolution text that will keep the distinction by adding - instead of replacing - the missing 'null' notion (which has to be taken from UML). For compatibility, since up to now, OCL writers have used oclIsUndefined() for both situations (real invalid values and 'null'), I suggest to introduce a new operation called oclIsInvalid(). The operation oclIsUndefined() will return true in both cases (invalid values and null values) whereas oclIsInvalid() will return true only for invalid values (values that are equal to the OclInvalid runtime singleton). -Mariano -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 18 mai 2005 05:32 À : Jos Warmer Cc : BELAUNDE Mariano RD-MAPS-LAN; ocl2-ftf@omg.org Objet : Re: OCL-FTF: OclUndefined versus null literal (issue 5972) I second Jos opinion. To me, "null" connotes emptiness -- a well-defined notion. OTOH, "undefined" implies that something has not been fully defined. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Jos Warmer 05/17/2005 03:41 PM To "BELAUNDE Mariano RD-MAPS-LAN" cc Subject Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Date: Thu, 19 May 2005 11:04:52 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Thread-Index: AcVbWkotPdW5RdBTQ2GgnH04qL7XFQAGkBtgADYsz4AAAR0KcA== From: "BELAUNDE Mariano RD-MAPS-LAN" To: "Anders Ivner" , "Branislav Selic" , "Jos Warmer" Cc: X-OriginalArrivalTime: 19 May 2005 09:04:53.0931 (UTC) FILETIME=[D23DF7B0:01C55C51] >>> Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? Yes. OclInvalid is the value carried by an illegal operation such as 5/0 (division by zero) whereas 'null' represents the "absence of value" (UML meaning) - for instance when accessing optional properties. To make the analogy with Java , OclInvalid corresponds to an exception wheres the java 'null' value is a valid value that can be freely manipulated (added into a list, passed as an actual argument of an operation and so on). -Mariano -----Message d'origine----- De : Anders Ivner [mailto:Anders.Ivner@borland.com] Envoyé : jeudi 19 mai 2005 10:48 À : BELAUNDE Mariano RD-MAPS-LAN; Branislav Selic; Jos Warmer Cc : ocl2-ftf@omg.org Objet : RE: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 18 maj 2005 09:15 To: Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Jos and Bran, You are certainly right to want to maintain the distinction between these two concepts. Division by zero fits typically in the invalid category and cannot be considered being an ordinary 'null' value. So following Jos suggestion for the second option, I propose to write a resolution text that will keep the distinction by adding - instead of replacing - the missing 'null' notion (which has to be taken from UML). For compatibility, since up to now, OCL writers have used oclIsUndefined() for both situations (real invalid values and 'null'), I suggest to introduce a new operation called oclIsInvalid(). The operation oclIsUndefined() will return true in both cases (invalid values and null values) whereas oclIsInvalid() will return true only for invalid values (values that are equal to the OclInvalid runtime singleton). -Mariano -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 18 mai 2005 05:32 À : Jos Warmer Cc : BELAUNDE Mariano RD-MAPS-LAN; ocl2-ftf@omg.org Objet : Re: OCL-FTF: OclUndefined versus null literal (issue 5972) I second Jos opinion. To me, "null" connotes emptiness -- a well-defined notion. OTOH, "undefined" implies that something has not been fully defined. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Jos Warmer 05/17/2005 03:41 PM To "BELAUNDE Mariano RD-MAPS-LAN" cc Subject Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: RE: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Date: Thu, 19 May 2005 11:34:43 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Thread-Index: AcVbWkotPdW5RdBTQ2GgnH04qL7XFQAGkBtgADYsz4AAAR0KcAAAo6GA From: "Anders Ivner" To: "BELAUNDE Mariano RD-MAPS-LAN" , "Branislav Selic" , "Jos Warmer" Cc: X-OriginalArrivalTime: 19 May 2005 09:34:52.0156 (UTC) FILETIME=[021153C0:01C55C56] Oh, I see. But that's what OclUndefined is supposed to be already. I'd rather we didn't change that, and instead went with Jos' suggestion #2 and added a NullLiteral. Note that a NullLiteral (and not just the OclIsNull() operation) is needed anyway if null values are to be handled fully as valid values of OCL expressions. Consider if someCollection->size() > 0 then someCollection->first() else null /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 19 maj 2005 11:05 To: Anders Ivner; Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) >>> Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? Yes. OclInvalid is the value carried by an illegal operation such as 5/0 (division by zero) whereas 'null' represents the "absence of value" (UML meaning) - for instance when accessing optional properties. To make the analogy with Java , OclInvalid corresponds to an exception wheres the java 'null' value is a valid value that can be freely manipulated (added into a list, passed as an actual argument of an operation and so on). -Mariano -----Message d'origine----- De : Anders Ivner [mailto:Anders.Ivner@borland.com] Envoyé : jeudi 19 mai 2005 10:48 À : BELAUNDE Mariano RD-MAPS-LAN; Branislav Selic; Jos Warmer Cc : ocl2-ftf@omg.org Objet : RE: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 18 maj 2005 09:15 To: Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Jos and Bran, You are certainly right to want to maintain the distinction between these two concepts. Division by zero fits typically in the invalid category and cannot be considered being an ordinary 'null' value. So following Jos suggestion for the second option, I propose to write a resolution text that will keep the distinction by adding - instead of replacing - the missing 'null' notion (which has to be taken from UML). For compatibility, since up to now, OCL writers have used oclIsUndefined() for both situations (real invalid values and 'null'), I suggest to introduce a new operation called oclIsInvalid(). The operation oclIsUndefined() will return true in both cases (invalid values and null values) whereas oclIsInvalid() will return true only for invalid values (values that are equal to the OclInvalid runtime singleton). -Mariano -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 18 mai 2005 05:32 À : Jos Warmer Cc : BELAUNDE Mariano RD-MAPS-LAN; ocl2-ftf@omg.org Objet : Re: OCL-FTF: OclUndefined versus null literal (issue 5972) I second Jos opinion. To me, "null" connotes emptiness -- a well-defined notion. OTOH, "undefined" implies that something has not been fully defined. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Jos Warmer 05/17/2005 03:41 PM To "BELAUNDE Mariano RD-MAPS-LAN" cc Subject Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: RE: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Date: Thu, 19 May 2005 11:41:37 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Thread-Index: AcVbWkotPdW5RdBTQ2GgnH04qL7XFQAGkBtgADYsz4AAAR0KcAAAo6GAAAB07yA= From: "Anders Ivner" To: "BELAUNDE Mariano RD-MAPS-LAN" , "Branislav Selic" , "Jos Warmer" Cc: X-OriginalArrivalTime: 19 May 2005 09:41:41.0075 (UTC) FILETIME=[F5CD6A30:01C55C56] I just saw this from the other mail. Clears thing up for me. Sorry for jumping to conclusions. >4) The metaclasses InvalidType and VoidType will be used to represent the type of the singletons >values OclInvalid (renaming of OclUndefined) and null (see previous mail discussion). The literals >expressions InvalidLiteralExp and NullLiteralExp are used to refer to these two runtime values. ...but just a small question. Is InvalidLiteralExp needed? /Anders -----Original Message----- From: Anders Ivner Sent: den 19 maj 2005 11:30 To: 'BELAUNDE Mariano RD-MAPS-LAN'; Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Oh, I see. But that's what OclUndefined is supposed to be already. I'd rather we didn't change that, and instead went with Jos' suggestion #2 and added a NullLiteral. Note that a NullLiteral (and not just the OclIsNull() operation) is needed anyway if null values are to be handled fully as valid values of OCL expressions. Consider if someCollection->size() > 0 then someCollection->first() else null /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 19 maj 2005 11:05 To: Anders Ivner; Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) >>> Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? Yes. OclInvalid is the value carried by an illegal operation such as 5/0 (division by zero) whereas 'null' represents the "absence of value" (UML meaning) - for instance when accessing optional properties. To make the analogy with Java , OclInvalid corresponds to an exception wheres the java 'null' value is a valid value that can be freely manipulated (added into a list, passed as an actual argument of an operation and so on). -Mariano -----Message d'origine----- De : Anders Ivner [mailto:Anders.Ivner@borland.com] Envoyé : jeudi 19 mai 2005 10:48 À : BELAUNDE Mariano RD-MAPS-LAN; Branislav Selic; Jos Warmer Cc : ocl2-ftf@omg.org Objet : RE: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 18 maj 2005 09:15 To: Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Jos and Bran, You are certainly right to want to maintain the distinction between these two concepts. Division by zero fits typically in the invalid category and cannot be considered being an ordinary 'null' value. So following Jos suggestion for the second option, I propose to write a resolution text that will keep the distinction by adding - instead of replacing - the missing 'null' notion (which has to be taken from UML). For compatibility, since up to now, OCL writers have used oclIsUndefined() for both situations (real invalid values and 'null'), I suggest to introduce a new operation called oclIsInvalid(). The operation oclIsUndefined() will return true in both cases (invalid values and null values) whereas oclIsInvalid() will return true only for invalid values (values that are equal to the OclInvalid runtime singleton). -Mariano -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 18 mai 2005 05:32 À : Jos Warmer Cc : BELAUNDE Mariano RD-MAPS-LAN; ocl2-ftf@omg.org Objet : Re: OCL-FTF: OclUndefined versus null literal (issue 5972) I second Jos opinion. To me, "null" connotes emptiness -- a well-defined notion. OTOH, "undefined" implies that something has not been fully defined. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Jos Warmer 05/17/2005 03:41 PM To "BELAUNDE Mariano RD-MAPS-LAN" cc Subject Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl Subject: RE : RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Date: Thu, 19 May 2005 11:57:11 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Thread-Index: AcVbWkotPdW5RdBTQ2GgnH04qL7XFQAGkBtgADYsz4AAAR0KcAAAo6GAAAB07yAAAG97EA== From: "BELAUNDE Mariano RD-MAPS-LAN" To: "Anders Ivner" , "Branislav Selic" , "Jos Warmer" Cc: X-OriginalArrivalTime: 19 May 2005 09:57:13.0426 (UTC) FILETIME=[2186E320:01C55C59] >>> ...but just a small question. Is InvalidLiteralExp needed? This is an interesting question ... I think InvalidLiteralExp is strictly needed only if we want to allow the users to explicit refer to the value. if x==OclInvalid then ... // same as if x.oclIsInvalid() ... I don't have a strong opinion on this ... -Mariano -----Message d'origine----- De : Anders Ivner [mailto:Anders.Ivner@borland.com] Envoyé : jeudi 19 mai 2005 11:42 À : BELAUNDE Mariano RD-MAPS-LAN; Branislav Selic; Jos Warmer Cc : ocl2-ftf@omg.org Objet : RE: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) I just saw this from the other mail. Clears thing up for me. Sorry for jumping to conclusions. >4) The metaclasses InvalidType and VoidType will be used to represent the type of the singletons >values OclInvalid (renaming of OclUndefined) and null (see previous mail discussion). The literals >expressions InvalidLiteralExp and NullLiteralExp are used to refer to these two runtime values. ...but just a small question. Is InvalidLiteralExp needed? /Anders -----Original Message----- From: Anders Ivner Sent: den 19 maj 2005 11:30 To: 'BELAUNDE Mariano RD-MAPS-LAN'; Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Oh, I see. But that's what OclUndefined is supposed to be already. I'd rather we didn't change that, and instead went with Jos' suggestion #2 and added a NullLiteral. Note that a NullLiteral (and not just the OclIsNull() operation) is needed anyway if null values are to be handled fully as valid values of OCL expressions. Consider if someCollection->size() > 0 then someCollection->first() else null /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 19 maj 2005 11:05 To: Anders Ivner; Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : RE : OCL-FTF: OclUndefined versus null literal (issue 5972) >>> Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? Yes. OclInvalid is the value carried by an illegal operation such as 5/0 (division by zero) whereas 'null' represents the "absence of value" (UML meaning) - for instance when accessing optional properties. To make the analogy with Java , OclInvalid corresponds to an exception wheres the java 'null' value is a valid value that can be freely manipulated (added into a list, passed as an actual argument of an operation and so on). -Mariano -----Message d'origine----- De : Anders Ivner [mailto:Anders.Ivner@borland.com] Envoyé : jeudi 19 mai 2005 10:48 À : BELAUNDE Mariano RD-MAPS-LAN; Branislav Selic; Jos Warmer Cc : ocl2-ftf@omg.org Objet : RE: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Is there a reason to call it OclInvalid rather than OclNull, if that's what it's representing? /Anders -----Original Message----- From: BELAUNDE Mariano RD-MAPS-LAN [mailto:mariano.belaunde@francetelecom.com] Sent: den 18 maj 2005 09:15 To: Branislav Selic; Jos Warmer Cc: ocl2-ftf@omg.org Subject: RE : OCL-FTF: OclUndefined versus null literal (issue 5972) Jos and Bran, You are certainly right to want to maintain the distinction between these two concepts. Division by zero fits typically in the invalid category and cannot be considered being an ordinary 'null' value. So following Jos suggestion for the second option, I propose to write a resolution text that will keep the distinction by adding - instead of replacing - the missing 'null' notion (which has to be taken from UML). For compatibility, since up to now, OCL writers have used oclIsUndefined() for both situations (real invalid values and 'null'), I suggest to introduce a new operation called oclIsInvalid(). The operation oclIsUndefined() will return true in both cases (invalid values and null values) whereas oclIsInvalid() will return true only for invalid values (values that are equal to the OclInvalid runtime singleton). -Mariano -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mercredi 18 mai 2005 05:32 À : Jos Warmer Cc : BELAUNDE Mariano RD-MAPS-LAN; ocl2-ftf@omg.org Objet : Re: OCL-FTF: OclUndefined versus null literal (issue 5972) I second Jos opinion. To me, "null" connotes emptiness -- a well-defined notion. OTOH, "undefined" implies that something has not been fully defined. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com Jos Warmer 05/17/2005 03:41 PM To "BELAUNDE Mariano RD-MAPS-LAN" cc Subject Re: OCL-FTF: OclUndefined versus null literal (issue 5972) Mariano, I agree with the fact that NullLiteral is useful, and a part of UML and thus should be included as part of OCL as well. I see two options here: 1 replace OclUndefined by NullLiteral 2 keep OclUndefined and add NullLiteral as a separate concept The consequence of option 1 is that,m even in the case of something really being incorrect an OClExpression would still return a valid value (i.e. NullLiteral). Users cannot distinguish between the two, which is sometimes neccesary. This is e.g. the case wehn I navigate a Null value and take an attribute of this, it should evaluate to oclundefined (like NullPointerException in java). Because of this, I prefer the second option. Jos At 06:10 PM 5/17/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, Thanks Jos for the clarification regarding OclUndefined. The intention of the current draft is then clearly to consider OclUndefined as not being a valid value (in constrast with the 'null' value in Java). In other words OclUndefined is not compatible with the notion of NullLiteral. Nevertheless, despite the original intention of the draft, I tend to think that the FTF need to change this, because of a major alignment problem with UML2. In effect, in UML the LiteralNull metaclass is explicitly defined as a valid value representing the absence of value. In contrast, in the current OCL spec, the absence of value does not produces something that we can manipulate (except for checking it). If the semantics of the singleton instance of VoidType is the semantics of a valid null value, then, apart from solving the alignment problem, we also solve the major deficiency in the expressivity of OCL - as a query language - which is pointed out by the author of issue 5972. Having a very restrictive semantics for the "absence of value" is really error prone when using collection operations in conjunction with properties with 0..1 multiplicity. I would like to know if someone is opposed to re-aligning the semantics of "absence of value" of OCL with the one of UML (which is also the one used by most of existing object-oriented languages). Regards, Mariano -----Message d'origine----- De : Jos Warmer [mailto:J.Warmer@klasse.nl] Envoyé : lundi 16 mai 2005 20:51 À : BELAUNDE Mariano RD-MAPS-LAN Cc : ocl2-ftf@omg.org Objet : Re: OCL-FTF: Question about issues 5970 and 5972 Hi all, below are my thoughts. Jos At 07:22 PM 5/16/2005, BELAUNDE Mariano RD-MAPS-LAN wrote: Hi all, I would like to know whether someone has an opinion regarding the issues 5970 (flatten) and issue 5972 (can collections contain void/undefined objects?). If the flatten operation is really a deep flatten operation, is the definition of Set::flatten below erroneous: result = if self.type.elementType.oclIsKindOf(CollectionType) then self->iterate(c; acc : Set() = Set{} | acc->union(c->asSet() ) ) else self endif Flatten should be a one level flatten and a additional operation "deepFlatten" should be added. There is a need for both variants. Regarding issue 5972, if I inspect a list of attributes where only some of them have a defaultValue defined, what will be the result of the expression: 'myAttributeList->collect(a|a.defaultValue)'. A list containing OclUndefined values or the OclUndefined value itself? The OCL 2 Draft states: In general an expression where one of the parts is undefined will itself be undefined. (Section 7.4 Undefined Values) Based on this the above should return OclUndefined. This in line with the intention that OclUndefined is _not_ a valid value (like e.g. null in Java), but OclUndefined means that the expression cannot be evaluated. The alternative is to use OclUndefined as a well-defined value. In that case a different name is probably better, and we need to check all uses of OclUndefined. PS: I am not sure what the example means. It seems to refer to the metalevel by using aatributes and their default values. To be sure about the answer, we need the corresponding calss model. Regards, Mariano _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl