Issue 2224:  Should Reflective.DesignatorType be "string"? (mof-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: The Reflective interfaces currently use object references to
 "designate" the feature (etc) to which a reflective operation applies.
 In practice, I am finding that this is inconvenient for clients of the
 API and potentially difficult for implementations.  I suggest that we
 reconsider the alternative; i.e. designating features using CORBA
 strings.
 
 

Resolution: 
Revised Text: 
Actions taken:
November 19, 1998: received issue
Discussion: 

End of Annotations:=====
Return-Path: <crawley@dstc.edu.au>
X-Exmh-Isig-CompType: unknown
X-Exmh-Isig-Folder: inbox
To: issues@omg.org, mof-rtf@omg.org
Subject: Should Reflective.DesignatorType be 'string'?
Date: Thu, 19 Nov 1998 14:26:56 +1000
From: Stephen Crawley <crawley@dstc.edu.au>


Source: DSTC (Stephen Crawley, crawley@dstc.edu.au)
Nature: Revision
Severity: Minor
Summary: The Reflective interfaces currently use object references to
"designate" the feature (etc) to which a reflective operation applies.
In practice, I am finding that this is inconvenient for clients of the
API and potentially difficult for implementations.  I suggest that we
reconsider the alternative; i.e. designating features using CORBA
strings.

Additional text:

This issue was debated while we were writing the MOF final submission.
However, the strongest proponent of the current approach recently
mentioned that he is having second thoughts.  Therefore, and in the
light of my own experience, I would like to revisit the issue.

---

A common pattern for a client of the reflective interface is as
follows:

  Reflective.RefObject x = ...

  // ... assuming that the program knows that the meta-object 'x' has
an 
  // attribute called 'foo'

  Model.Class cl = Class.narrow(x.meta_object());
  Model.Attribute attr = Attribute.narrow(cl.lookup_element("foo"));

  Any res = x.value(attr);  // here the attr value is the 'designator'
                            // [Attribute is a subtype of RefObject]

This is rather cumbersome, especially if you add the exception
handlers.  If the application programmer could express the designator
as a CORBA string, the code would be a lot simpler, and would involve
fewer CORBA invocations.

  Any res = x.value("foo");

or maybe 

  Any res = x.value("SomeClass.foo");

---

The implementation side argument is more subtle.

It is undoubtedly the case that an implementation can compare object
references (with Object::_is_equivalent()) just as easily as it can
compare strings.  The difference in runtime overheads is probably
marginal compared to the other overheads.  [Not enough to justify
a change IMO.]

However, the problems arise when we consider the case when the
'designator' object reference supplied by the client does not denote
an (M2) meta-object that is colocated with the (M1) metadata.  In this
case, Object::_is_equivalent() may not return true.  The expected and
supplied designator references could be different references for the
same (M2) meta-objects.  Worse, they could be IORs for different
replica meta-objects for the same M2 model element.  In the worst
case, it may be impossible to access one or other of the M2 meta-
objects to compare them!

Doing a thorough job of distinguishing the various cases in a
federated system is likely to be complicated and expensive.  Using
CORBA strings as designators would neatly side-step the problem,
improving both efficiency and reliability.

---