Issue 2195:  Error in "args" parameter of RefObject::invoke_operation. (mof-rtf)
Source:  (, )
Nature:  Revision
Severity:  Minor
Summary: Summary: The ValueTypeList argument should be an "inout" instead of 
 an "in" parameter.  Otherwise, a client cannot see values passed
 back using "out" or "inout" parameters in a specific operation.
 
 Additional text:
 

Resolution: closed resolved
Revised Text: 
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue
Discussion: 
Implementation: Changed the "args" parameter to be "inout" instead of "in" in
Section 6.2.3, “Reflective::RefObject,” on page 6-10 and in the
RefObject interface in Appendix B.2 “MOF IDL Summary”. Done.
[KR]
Implementation: Rewrote text that covers encoding of all Parameters including the
return value to remove ambiguities; see Section 6.2.3, “Reflec-tive::
RefObject,” on page 6-10 . Done [SC].
End of Annotations:=====
Return-Path: <crawley@dstc.edu.au>
To: mof-rtf@omg.org, issues@omg.org
Subject: Issues with the MOF Reflective interfaces
Date: Sat, 07 Nov 1998 02:04:02 +1000
From: Stephen Crawley <crawley@dstc.edu.au>


This message contains a set of issues that DSTC have discovered while
implementing the MOF Reflective interfaces.  Don't panic.  They are
all "minor" :-)

Credit for finding them and carefully documenting them is due to
Douglas Kosovic.

-- Steve
Subject: Error in 'args' parameter of RefObject::invoke_operation.
Source: DSTC (Douglas Kosovic, douglask@dstc.edu.au)
Nature: Revision
Severity: Minor
Summary: The ValueTypeList argument should be an 'inout' instead of 
an 'in' parameter.  Otherwise, a client cannot see values passed
back using 'out' or 'inout' parameters in a specific operation.

Additional text:

The proposed signature is:

  ValueType invoke_operation (in DesignatorType requested_operation,
                              inout ValueTypeList args)

For example:

Say we have the following interface specific operation.
  op(in p1, out p2, inout p3)

The ValueTypeList parameter value on input will be something like:

  { (valid value), (don't care), (valid value)}

and on output after processing something like:

  { tk_null, (valid value), (valid value)}

It would be nice if input parameter positions contain a tk_null on
output like the above example, but there is no real justification for
requiring them to do so.

Also, perhaps tk_void should be returned for operations that are
defined
returning a void?