Issue 2839: Do non-public Attributes need initialising? (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Minor Summary: Summary: It is not clearly stated in Section 5.8.9 whether or not a Class"e "create_<classname>" operation should have parameters to provide initial values for Attributes whose visibility is "protected_vis" or "private_vis". The same applies for 5.8.3 for classifier-level Attributes in the Package factory interface. Resolution: Revised Text: Actions taken: August 12, 1999: received issue Discussion: End of Annotations:===== X-Mailer: exmh version 2.0.2 2/24/98 To: mof-rtf@omg.org, issues@omg.org Subject: Do non-public Attributes need initialising? Date: Thu, 12 Aug 1999 15:45:04 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Severity: Minor Summary: It is not clearly stated in Section 5.8.9 whether or not a Class'e "create_" operation should have parameters to provide initial values for Attributes whose visibility is "protected_vis" or "private_vis". The same applies for 5.8.3 for classifier-level Attributes in the Package factory interface. Discussion: Not specifying this clearly is an oversight (mea culpa). I recall that this was discussed within the core RTF team, though I cannot recall what the outcome was. If we say that an initial value argument IS present, this kind of goes against the notion of what "private" and "protected" generally mean. In particular, we are expecting a public client to know what is an appropriate value to supply, If we say that an initial value argument IS NOT present, this raises the issue of where the initial value should come from. [A reasonable answer is that this is implementation specific ... in the same way that specifying the semantics of Operations is implementation specific.] My personal preference is to say that the initial value argument(s) should NOT be present for private and protected Attributes in either the Package or Class factory operations. Either way, this does not affect generated interfaces for the MOF Model or (as far as I know) the UML meta-model. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: mof-rtf@omg.org Subject: Re: Issue 2839: Do non-public Attributes need initialising? Mime-Version: 1.0 Date: Thu, 11 Oct 2001 00:21:27 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: _E=e9)]1!!~6@e9&5`d9 Folks, Here is my proposal for resolving issue 2839. Any comments? -- Steve > Nature: Uncategorized Issue > Severity: Minor > Summary: > It is not clearly stated in Section 5.8.9 whether or not a Class"e > "create_" operation should have parameters to provide > initial values for Attributes whose visibility is "protected_vis" or > "private_vis". The same applies for 5.8.3 for classifier-level > Attributes in the Package factory interface. Proposed Resolution: "Clarify text to say that only 'public_vis' Attributes have initial value parameters. Note: support for protected and private Attributes is is beyond the scope of the MOF IDL mapping. This includes mechanisms for initialising protected and private Attribute values. It would be a violation of object encapsulation to provide a public (i.e. IDL) API for initialising protected and private state." Proposed Revised Text: In Section 5.8.3, change the template "// for each non-derived class-level Attribute ..." to read: "// for each public, non-derived, class-level Attribute ..." Change the first paragraph after the table from: "... give initial values for any non-derived classifier-scoped Attributes ..." to read: "... give initial values for any public, non-derived, classifier-scoped Attributes ..." In Section 5.8.9, change the template "// for each non-derived direct or inherited attribute" to read: "// for each public, non-derived direct or inherited attribute" Change the first paragraph after the table, replacing "non-derived" with "public, non-derived, instance-level". Change item 4 of the numbered list to insert the following phrase after "is encountered with": "a ''visibility'' value of ''private_vis'' or ''protected_vis'', " Importance: Normal Subject: Re: Issue 2839: Do non-public Attributes need initialising? To: Stephen Crawley Cc: mof-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Stephen Brodsky" Date: Wed, 10 Oct 2001 13:14:40 -0700 X-MIMETrack: Serialize by Router on D03NM039/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 02:17:32 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: RK1e9!G&e9FR$e9I/De9 Steve, Makes sense, although I would prefer having no arguments, which is where I think we are with JMI. On the names, if I recall correctly, the IDL name is "private_vis" but the name in the MOF model is/should be "private". I recall this was discussed during a MOF 1.4 telecon. 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 Stephen Crawley on 10/10/2001 07:21:27 AM To: mof-rtf@omg.org cc: Subject: Re: Issue 2839: Do non-public Attributes need initialising? Folks, Here is my proposal for resolving issue 2839. Any comments? -- Steve > Nature: Uncategorized Issue > Severity: Minor > Summary: > It is not clearly stated in Section 5.8.9 whether or not a Class"e > "create_" operation should have parameters to provide > initial values for Attributes whose visibility is "protected_vis" or > "private_vis". The same applies for 5.8.3 for classifier-level > Attributes in the Package factory interface. Proposed Resolution: "Clarify text to say that only 'public_vis' Attributes have initial value parameters. Note: support for protected and private Attributes is is beyond the scope of the MOF IDL mapping. This includes mechanisms for initialising protected and private Attribute values. It would be a violation of object encapsulation to provide a public (i.e. IDL) API for initialising protected and private state." Proposed Revised Text: In Section 5.8.3, change the template "// for each non-derived class-level Attribute ..." to read: "// for each public, non-derived, class-level Attribute ..." Change the first paragraph after the table from: "... give initial values for any non-derived classifier-scoped Attributes ..." to read: "... give initial values for any public, non-derived, classifier-scoped Attributes ..." In Section 5.8.9, change the template "// for each non-derived direct or inherited attribute" to read: "// for each public, non-derived direct or inherited attribute" Change the first paragraph after the table, replacing "non-derived" with "public, non-derived, instance-level". Change item 4 of the numbered list to insert the following phrase after "is encountered with": "a ''visibility'' value of ''private_vis'' or ''protected_vis'', " X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Stephen Brodsky" cc: Stephen Crawley , mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: Issue 2839: Do non-public Attributes need initialising? In-Reply-To: Message from "Stephen Brodsky" of "Wed, 10 Oct 2001 13:14:40 MST." Mime-Version: 1.0 Date: Thu, 11 Oct 2001 10:54:57 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: ]$7e9)Cmd9"]'e9OKfd9 Steve, > Makes sense, although I would prefer having no arguments, which is where I > think we are with JMI. In JMI, there are two "factory" operations, one with arguments and one without. In the no-argument case, JMI relies on returning "null" to say that an Attribute value is uninitialised. You can't do this in IDL, at least not for data types. So all Attribute getter operations would need to throw some new IDL exception. Changing the IDL mapping to no argument factory operations would have significant impact on the IDL mapping, IDL-based MOF repositories and IDL-based MOF clients. IMO, we should not touch this in MOF 1.5. > On the names, if I recall correctly, the IDL name is "private_vis" but the > name in the MOF model is/should be "private". I recall this was discussed > during a MOF 1.4 telecon. Actually, both the IDL name and the metamodel name are "private_vis", and we cannot make them different without defining a new IDL mapping Tag. Again, I don't think we should touch this in MOF 1.5. -- Steve