Issue 4151: Passing two context lists to _create_request() (cxx_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: The second version of _create_request() accepts two context lists: void Object::_create_request( Context_ptr ctx, // <=== const char * operation, NVList_ptr arg_list, NamedValue_ptr result, ExceptionList_ptr, ContextList_ptr, // <=== Request_out request, Flags req_flags ); The spec then says: The ContextList differs from the Context in that the former supplies only the context strings whose values are to be looked up and sent with the request invocation (if applicable), while the latter is where those values are obtained. So, I *think* (but I'm not sure), this means to say that: - The Context parameter points at a tree of context objects. - The ContextList pointer points at an object that contains a sequence of strings. - The ContextList determines which context values are to be picked out of the tree pointed at by the Context parameter and to be sent with the invocation. If that is the intended interpretation, it's very difficult to discern from the words in the spec now. I think this needs clarification. Questions: - What happens if the ContextList contains the name of a context variable that isn't available in the context tree? - What happens if I have a non-empty context list but a nil context tree? Also, looking at the ContextList interface: pseudo interface ContextList { readonly attribute unsigned long count; void add(in string ctxt); string item(in unsigned long index) raises(Bounds); void remove(in unsigned long index) raises(Bounds); }; There is no further documentation on this. Some questions: - As far as I can see, this interface is meant to maintain a simple sequence of strings. So, why not simply use a string sequence? - At what position does add() add the item? Presumably at the tail, but that isn't stated. - How can I replace the value of string at a certain position? It looks like I can't do that at all because there is no random-access modifier. This seems insanely complex. Suggestion: We should - add words to make it clear how the context parameters work - consider overloading _create_request() yet again to use an ordinary string sequence - deprecate the ContextList pseudo interface Or, we could drop support for IDL context altogether (but I suspect we can't get away with that ;-) Resolution: Revised Text: Actions taken: January 16, 2001: received issue Discussion: End of Annotations:===== Date: Tue, 16 Jan 2001 11:41:06 +1000 (EST) From: Michi Henning Reply-To: C++ Revision Task Force To: C++ Revision Task Force cc: issues@omg.org Subject: Passing two context lists to _create_request() Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: [D@e9!@A!!,%Od9boZ!! The second version of _create_request() accepts two context lists: void Object::_create_request( Context_ptr ctx, // <=== const char * operation, NVList_ptr arg_list, NamedValue_ptr result, ExceptionList_ptr, ContextList_ptr, // <=== Request_out request, Flags req_flags ); The spec then says: The ContextList differs from the Context in that the former supplies only the context strings whose values are to be looked up and sent with the request invocation (if applicable), while the latter is where those values are obtained. So, I *think* (but I'm not sure), this means to say that: - The Context parameter points at a tree of context objects. - The ContextList pointer points at an object that contains a sequence of strings. - The ContextList determines which context values are to be picked out of the tree pointed at by the Context parameter and to be sent with the invocation. If that is the intended interpretation, it's very difficult to discern from the words in the spec now. I think this needs clarification. Questions: - What happens if the ContextList contains the name of a context variable that isn't available in the context tree? - What happens if I have a non-empty context list but a nil context tree? Also, looking at the ContextList interface: pseudo interface ContextList { readonly attribute unsigned long count; void add(in string ctxt); string item(in unsigned long index) raises(Bounds); void remove(in unsigned long index) raises(Bounds); }; There is no further documentation on this. Some questions: - As far as I can see, this interface is meant to maintain a simple sequence of strings. So, why not simply use a string sequence? - At what position does add() add the item? Presumably at the tail, but that isn't stated. - How can I replace the value of string at a certain position? It looks like I can't do that at all because there is no random-access modifier. This seems insanely complex. Suggestion: We should - add words to make it clear how the context parameters work - consider overloading _create_request() yet again to use an ordinary string sequence - deprecate the ContextList pseudo interface Or, we could drop support for IDL context altogether (but I suspect we can't get away with that ;-) Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@corvette.floorboard.com Message-ID: <3A6504DC.D98D3E57@floorboard.com> Date: Tue, 16 Jan 2001 18:35:08 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: C++ Revision Task Force Subject: Re: Passing two context lists to _create_request() References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: i51!!ffQd9ITA!!C?X!! Michi Henning wrote: > > The second version of _create_request() accepts two context lists: > > void Object::_create_request( > Context_ptr ctx, // <=== > const char * operation, > NVList_ptr arg_list, > NamedValue_ptr result, > ExceptionList_ptr, > ContextList_ptr, // <=== > Request_out request, > Flags req_flags > ); > > The spec then says: > > The ContextList differs from the Context in that the former supplies > only the context strings whose values are to be looked up and sent > with the request invocation (if applicable), while the latter > is where those values are obtained. > > So, I *think* (but I'm not sure), this means to say that: > > - The Context parameter points at a tree of context objects. Yes. > - The ContextList pointer points at an object that contains > a sequence of strings. Yes. > - The ContextList determines which context values are to be > picked out of the tree pointed at by the Context parameter and > to be sent with the invocation. Yes. > If that is the intended interpretation, it's very difficult to discern > from the words in the spec now. I think this needs clarification. > > Questions: > > - What happens if the ContextList contains the name of a context > variable that isn't available in the context tree? It isn't sent. I believe it is optional to actually have a Context value that the operation specifies as transmitted. > - What happens if I have a non-empty context list but a nil > context tree? Nothing should be sent. > Also, looking at the ContextList interface: > > pseudo interface ContextList { > readonly attribute unsigned long count; > void add(in string ctxt); > string item(in unsigned long index) raises(Bounds); > void remove(in unsigned long index) raises(Bounds); > }; > > There is no further documentation on this. Some questions: > > - As far as I can see, this interface is meant to maintain a > simple sequence of strings. So, why not simply use a > string > sequence? Somebody goofed and defined a PO when a 'typedef sequence ContextList' would have worked. > - At what position does add() add the item? Presumably at the tail, > but that isn't stated. I suppose. > - How can I replace the value of string at a certain position? > It looks like I can't do that at all because there is no > random-access modifier. Right. > This seems insanely complex. Right. > Suggestion: We should > > - add words to make it clear how the context parameters work > > - consider overloading _create_request() yet again to use > an ordinary string sequence Could do the same with ExceptionList as well, since it is really just a sequence of RepositoryIds. > - deprecate the ContextList pseudo interface > > Or, we could drop support for IDL context altogether (but I suspect > we > can't get away with that ;-) You've got my vote, but it's the wrong RTF. :( -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org