CPP13 — Passing two context lists to _create_request()

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

;

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