Issue 4419: Disallow null instance values (mof-rtf) Source: DSTC (Dr. Stephen Crawley, nobody) Nature: Revision Severity: Significant Summary: It can be argued that there is no need to allow null as a valid value for a Class instance. The possibility of null means that mapped APIs need to be more complicated; e.g. the IDL "unset_*" operations. This issue proposes that 'null' should be disallowed, making Class instances consistent with DataType instances. The IDL mapping could also be simplified. Resolution: Revised Text: Actions taken: July 25, 2001: received issue Discussion: [Steve Crawley] We need to carefully consider the impact of this proposed change. I strongly recommend that we don't try to do this in MOF 1.4 In normal programming languages where attributes are used to represent relationships between objects, a null value is typically used to signify the absence of a relationship. In MOF, the absence of a relationship can be modelled in other ways; e.g. using a [0..1] (optional) Attribute or Association. However, there are other possible uses of null where there is no straight-forward alternative. We also need to consider the impact on the IDL mapping, specifically in how Class instances are created. Consider the following: class C { attribute C another_one; }; If null is not a legal value for a 'C' instance, what do you pass as the initial value for 'another_one' when creating the first ever instance of 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] Attribute for the metamodel to be practical. Or maybe each mapping needs to find a solution; e.g. by deferring checking of some structural constraint ... like the IDL mapping currently does for Association underflow. Note: It is currently explicitly illegal to use a null instance value in Association links and References. This would not change. [Steve Crawley] We need to carefully consider the impact of this proposed change. I strongly recommend that we don't try to do this in MOF 1.4 In normal programming languages where attributes are used to represent relationships between objects, a null value is typically used to signify the absence of a relationship. In MOF, the absence of a relationship can be modelled in other ways; e.g. using a [0..1] (optional) Attribute or Association. However, there are other possible uses of null where there is no straight-forward alternative. We also need to consider the impact on the IDL mapping, specifically in how Class instances are created. Consider the following: class C { attribute C another_one; }; If null is not a legal value for a 'C' instance, what do you pass as the initial value for 'another_one' when creating the first ever instance of 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] Attribute for the metamodel to be practical. Or maybe each mapping needs to find a solution; e.g. by deferring checking of some structural constraint ... like the IDL mapping currently does for Association underflow. Note: It is currently explicitly illegal to use a null instance value in Association links and References. This would not change. End of Annotations:===== X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: issues@omg.org cc: mof-rtf@omg.org Subject: Disallow null instance values Mime-Version: 1.0 Date: Wed, 25 Jul 2001 09:44:03 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: AJ_d9f+Le950&!!Xb`!! Nature: Revision Severity: Significant Summary: It can be argued that there is no need to allow null as a valid value for a Class instance. The possibility of null means that mapped APIs need to be more complicated; e.g. the IDL "unset_*" operations. This issue proposes that 'null' should be disallowed, making Class instances consistent with DataType instances. The IDL mapping could also be simplified. Discussion: [Steve Crawley] We need to carefully consider the impact of this proposed change. I strongly recommend that we don't try to do this in MOF 1.4 In normal programming languages where attributes are used to represent relationships between objects, a null value is typically used to signify the absence of a relationship. In MOF, the absence of a relationship can be modelled in other ways; e.g. using a [0..1] (optional) Attribute or Association. However, there are other possible uses of null where there is no straight-forward alternative. We also need to consider the impact on the IDL mapping, specifically in how Class instances are created. Consider the following: class C { attribute C another_one; }; If null is not a legal value for a 'C' instance, what do you pass as the initial value for 'another_one' when creating the first ever instance of 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] Attribute for the metamodel to be practical. Or maybe each mapping needs to find a solution; e.g. by deferring checking of some structural constraint ... like the IDL mapping currently does for Association underflow. Note: It is currently explicitly illegal to use a null instance value in Association links and References. This would not change. X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 4419: Disallow null instance values Mime-Version: 1.0 Date: Thu, 25 Oct 2001 16:07:37 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: Hgc!!]/'e9`I~!!Xbjd9 > Summary: It can be argued that there is no need to allow null as a valid > value for a Class instance. The possibility of null means that mapped APIs > need to be more complicated; e.g. the IDL "unset_*" operations. This issue > proposes that 'null' should be disallowed, making Class instances consistent > with DataType instances. The IDL mapping could also be simplified. > > Discussion: [Steve Crawley] We need to carefully consider the impact of > this proposed change. I strongly recommend that we don't try to do this in > MOF 1.4 In normal programming languages where attributes are used to > represent relationships between objects, a null value is typically used > to signify the absence of a relationship. In MOF, the absence of a > relationship can be modelled in other ways; e.g. using a [0..1] (optional) > Attribute or Association. However, there are other possible uses of null > where there is no straight-forward alternative. > > We also need to consider the impact on the IDL mapping, specifically in how > Class instances are created. Consider the following: > > class C { > attribute C another_one; > }; > > If null is not a legal value for a 'C' instance, what do you pass as the > initial value for 'another_one' when creating the first ever instance of > 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] > Attribute for the metamodel to be practical. Or maybe each mapping needs > to find a solution; e.g. by deferring checking of some structural constraint > ... like the IDL mapping currently does for Association underflow. > > Note: It is currently explicitly illegal to use a null instance value in > Association links and References. This would not change. OK folks, its now MOF 1.5, and we need to think about what to do about null Class instance values. Unless something extraordinary happens, JMI 1.0 will not support nulls as Class values (or DataType values). So we need to consider how / whether to align MOF 1.5 with JMI. Here are the feasible options I can think of: 1) Do nothing. Let MOF 2.0 sort this out. 2) Add text to MOF 1.5 to "deprecate" null Class instances, stating that JMI does not allow this. 3) In the Abstract mapping: a) disallow null Class instance values everywhere, and b) update the definitions of equality, the composition constraints and so on accordingly. In the IDL mapping: a) make enforcement of the underflow constraint on [1..1] Class-valued Attributes to "deferred", b) change the semantics of the create_ and create_ methods so that a "null" initial value for a [1..1] Class-valued Attribute initialises the value to the "underflow" state, c) change the semantics of the getter operation for [1..1] Class-valued Attributes to allow it to throw MofError with kind == Underflow, and d) add extra constraint checks to catch null Class instance values in other multiplicity Attributes, CollectionTypes and StructTypes, throwing MofError with kind == NilObject. In the XMI mapping (ACTION: xmi-rtf), support for null Class instances will need to be removed in XMI 1.3. The result of 1) and 2) is that passing metadata from a "real" MOF to a JMI MOF potentially leads to loss of information. (But in the case of 2), the user has some warning.) The result of 3) is that certain pre-MOF 1.5 metamodels and metadata won't be usable any more. In addition, vendors who implement MOF code generators will have some extra work to do. Have I missed anything? Any other (less painful) options? -- Steve From: "Baisley, Donald E" To: Stephen Crawley , mof-rtf@omg.org Subject: RE: Issue 4419: Disallow null instance values Date: Mon, 29 Oct 2001 13:43:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: i~-e9^AXd9~iV!! Summary: It can be argued that there is no need to allow null as a valid > value for a Class instance. The possibility of null means that mapped APIs > need to be more complicated; e.g. the IDL "unset_*" operations. This issue > proposes that 'null' should be disallowed, making Class instances consistent > with DataType instances. The IDL mapping could also be simplified. > > Discussion: [Steve Crawley] We need to carefully consider the impact of > this proposed change. I strongly recommend that we don't try to do this in > MOF 1.4 In normal programming languages where attributes are used to > represent relationships between objects, a null value is typically used > to signify the absence of a relationship. In MOF, the absence of a > relationship can be modelled in other ways; e.g. using a [0..1] (optional) > Attribute or Association. However, there are other possible uses of null > where there is no straight-forward alternative. > > We also need to consider the impact on the IDL mapping, specifically in how > Class instances are created. Consider the following: > > class C { > attribute C another_one; > }; > > If null is not a legal value for a 'C' instance, what do you pass as the > initial value for 'another_one' when creating the first ever instance of > 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] > Attribute for the metamodel to be practical. Or maybe each mapping needs > to find a solution; e.g. by deferring checking of some structural constraint > ... like the IDL mapping currently does for Association underflow. > > Note: It is currently explicitly illegal to use a null instance value in > Association links and References. This would not change. OK folks, its now MOF 1.5, and we need to think about what to do about null Class instance values. Unless something extraordinary happens, JMI 1.0 will not support nulls as Class values (or DataType values). So we need to consider how / whether to align MOF 1.5 with JMI. Here are the feasible options I can think of: 1) Do nothing. Let MOF 2.0 sort this out. 2) Add text to MOF 1.5 to "deprecate" null Class instances, stating that JMI does not allow this. 3) In the Abstract mapping: a) disallow null Class instance values everywhere, and b) update the definitions of equality, the composition constraints and so on accordingly. In the IDL mapping: a) make enforcement of the underflow constraint on [1..1] Class-valued Attributes to "deferred", b) change the semantics of the create_ and create_ methods so that a "null" initial value for a [1..1] Class-valued Attribute initialises the value to the "underflow" state, c) change the semantics of the getter operation for [1..1] Class-valued Attributes to allow it to throw MofError with kind == Underflow, and d) add extra constraint checks to catch null Class instance values in other multiplicity Attributes, CollectionTypes and StructTypes, throwing MofError with kind == NilObject. In the XMI mapping (ACTION: xmi-rtf), support for null Class instances will need to be removed in XMI 1.3. The result of 1) and 2) is that passing metadata from a "real" MOF to a JMI MOF potentially leads to loss of information. (But in the case of 2), the user has some warning.) The result of 3) is that certain pre-MOF 1.5 metamodels and metadata won't be usable any more. In addition, vendors who implement MOF code generators will have some extra work to do. Have I missed anything? Any other (less painful) options? -- Steve Importance: Normal Subject: RE: Issue 4419: Disallow null instance values To: "Baisley, Donald E" Cc: Stephen Crawley , mof-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Stephen Brodsky" Date: Mon, 29 Oct 2001 17:35:03 -0800 X-MIMETrack: Serialize by Router on D03NM039/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/29/2001 06:38:16 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: AQ9!!cngd9@!&!!^7Q!! Hi, I think we prefer option 3. Our goal is that objects can be created incrementally, starting with none of the features being set and then giving values to them one at a time as they become known. I would like to see all the mappings support this. Thanks, -Steve Stephen A. Brodsky, Ph.D. Software Architect, STSM Notes Address: Stephen Brodsky/Santa Teresa/IBM@IBMUS Internet Address: sbrodsky@us.ibm.com Phone: 408.463.5659 "Baisley, Donald E" on 10/29/2001 11:43:02 AM To: Stephen Crawley , mof-rtf@omg.org cc: Subject: RE: Issue 4419: Disallow null instance values We want option 3. Thanks, Don -----Original Message----- From: Stephen Crawley [mailto:crawley@dstc.edu.au] Sent: Wednesday, October 24, 2001 11:08 PM To: mof-rtf@omg.org Subject: Re: Issue 4419: Disallow null instance values > Summary: It can be argued that there is no need to allow null as a valid > value for a Class instance. The possibility of null means that mapped APIs > need to be more complicated; e.g. the IDL "unset_*" operations. This issue > proposes that 'null' should be disallowed, making Class instances consistent > with DataType instances. The IDL mapping could also be simplified. > > Discussion: [Steve Crawley] We need to carefully consider the impact of > this proposed change. I strongly recommend that we don't try to do this in > MOF 1.4 In normal programming languages where attributes are used to > represent relationships between objects, a null value is typically used > to signify the absence of a relationship. In MOF, the absence of a > relationship can be modelled in other ways; e.g. using a [0..1] (optional) > Attribute or Association. However, there are other possible uses of null > where there is no straight-forward alternative. > > We also need to consider the impact on the IDL mapping, specifically in how > Class instances are created. Consider the following: > > class C { > attribute C another_one; > }; > > If null is not a legal value for a 'C' instance, what do you pass as the > initial value for 'another_one' when creating the first ever instance of > 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] > Attribute for the metamodel to be practical. Or maybe each mapping needs > to find a solution; e.g. by deferring checking of some structural constraint > ... like the IDL mapping currently does for Association underflow. > > Note: It is currently explicitly illegal to use a null instance value in > Association links and References. This would not change. OK folks, its now MOF 1.5, and we need to think about what to do about null Class instance values. Unless something extraordinary happens, JMI 1.0 will not support nulls as Class values (or DataType values). So we need to consider how / whether to align MOF 1.5 with JMI. Here are the feasible options I can think of: 1) Do nothing. Let MOF 2.0 sort this out. 2) Add text to MOF 1.5 to "deprecate" null Class instances, stating that JMI does not allow this. 3) In the Abstract mapping: a) disallow null Class instance values everywhere, and b) update the definitions of equality, the composition constraints and so on accordingly. In the IDL mapping: a) make enforcement of the underflow constraint on [1..1] Class-valued Attributes to "deferred", b) change the semantics of the create_ and create_ methods so that a "null" initial value for a [1..1] Class-valued Attribute initialises the value to the "underflow" state, c) change the semantics of the getter operation for [1..1] Class-valued Attributes to allow it to throw MofError with kind == Underflow, and d) add extra constraint checks to catch null Class instance values in other multiplicity Attributes, CollectionTypes and StructTypes, throwing MofError with kind == NilObject. In the XMI mapping (ACTION: xmi-rtf), support for null Class instances will need to be removed in XMI 1.3. The result of 1) and 2) is that passing metadata from a "real" MOF to a JMI MOF potentially leads to loss of information. (But in the case of 2), the user has some warning.) The result of 3) is that certain pre-MOF 1.5 metamodels and metadata won't be usable any more. In addition, vendors who implement MOF code generators will have some extra work to do. Have I missed anything? Any other (less painful) options? -- Steve