Issue 1683: Convenient way to discriminate instances of subclasses (mof-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: The Reflective layer needs to provide an easy, universal way to identify the "most derived" class of a meta-object. At the moment, an application needs to make a sequence of "narrow" calls. In some situations, this is unavoidably network intensive. Resolution: resolved Revised Text: Actions taken: July 15, 1998: received issue July 23, 1999: closed issue Discussion: Discussion: (crawley@dstc.edu.au) I now think that this is unnecessary. Proposed resolution: close with no action. Implementation: Nothing to do. Done [KR]. End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: Convenient way to discriminate instances of subclasses Date: Wed, 15 Jul 1998 13:18:57 +1000 From: Stephen Crawley Source: DSTC (Dr Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Minor Summary: The Reflective layer needs to provide an easy, universal way to identify the "most derived" class of a meta-object. At the moment, an application needs to make a sequence of "narrow" calls. In some situations, this is unavoidably network intensive. Additional Text: My preferred resolution would be to add a new operation to either RefObject (or RefBaseObject) that returned a CORBA string containing the fully qualified name of a meta-object's Class (or Class / Package / Association). I know that RefBaseObject has an operation to return an M1-level meta-object's M2-level meta-meta-object. In many cases, this could be used to achieve the same ends. However 1) an implementation is (expressly I think) permitted to return a nil object reference instead of the M2-level meta-meta-object reference. 2) you can't reliably compare meta-meta-object references without performing an operation on them. So I don't think that approach works. Return-Path: Date: Thu, 30 Jul 1998 06:57:05 -0700 From: GK Khalsa Organization: Object Radiance, Inc. To: "mof-rtf@omg.org" Subject: Discussion of Issue 1711 Discussion of Issue 1711: Multiplicities on Attributes and References modelled incorrectly This issue was discussed at length during the development of the MOF Standard. Based on the current MOF modeling capabilities, we are faced with either (1) duplicating the multiplicity and isChangeable attributes in both the reference and association end; or (2) not treating attributes and references uniformly. We felt that the ability to treat references and attributes uniformly (since they both describe the state of the object) was most important. Crawley's suggestion of defining reference multiplicity separate from attribute multiplicity would not allow developers to treat both References and Attributes as StructuralFeatures when addressing multiplicity (and changeability). This limitation would also complicate implementation of the Reflective interfaces. Although the current model is a little peculiar, it poses no real problem. Remember, the presence of a MofAttribute in a model does not mandate any particular implementation. Because constraints synchronize the values of multiplicity and isChangeable attributes for Reference and AssociationEnd, implementations can hold the attribute values at a single location. The redundancy in the create_reference() operation can be addressed by defining a second constructor within the model. -- GK Khalsa khalsa@objectrad.com Object Radiance, Inc. v: +1 909 677 2518 Murrieta, CA USA f: +1 909 677 1478 Return-Path: To: GK Khalsa cc: "mof-rtf@omg.org" , crawley@dstc.edu.au Subject: Re: Discussion of Issue 1683 Date: Fri, 31 Jul 1998 10:46:02 +1000 From: Stephen Crawley GK, I am proposing something like. interface RefBaseObject { ... string meta_name(); }; For the purposes I envisage, this operation needs to return a name that: a) The programmer can deduce by looking at the 'source' for the meta-model he is looking at. b) Can be hard-coded into an application; i.e. doesn't need to be looked up at runtime. >From a) and b) it follows that the meta_names shouldn't have version info in them, because that changes, and they shouldn't depend on the location of the package in any "global" repository namespace, because that can be changed. Also, we cannot use globally unique identifiers as requested by Woody. Basically, any change to a meta-model or its context that doesn't change the generated IDL (against which the application is compiled) shouldn't change the meta_name. If it does, the application programmer can't hardwire the meta-names into his code, and the operation becomes pointless; i.e. it is easier to use narrow. At the moment, I think result should be a qualified name relative to the top level Package; e.g. for package foo { package bar { type baz {}; }; type mumble {}; }; the meta_names would be "foo", "foo::baf", "foo::bar::baz" and "foo::mumble" Actually, now that I come to think of it, if core CORBA defined a portable, efficient way to obtain the RepositoryId for the object, we'd be almost there. -- Steve