If we just want to have a string interface, I would prefer to
go back to language strings.
The only thing this proposal solves is the 255 character
limit in Fortran (on some machines). You still have all the
quoting issues. For instance:
String_create(&string);
String_append(&string, "my key = my value, my key2 =");
String_append(&string, "my value = 2");
Can you unambiguously name the key/value pairs in the above?
I didn't think so. One could write specific text explaining
*exactly* how the above should be interpreted and
*exactly* how String_create/etc. should be used, but
I think that proposal would be almost as complicated
as the current quoting mechanism. Perhaps what you
intend is adding a single key=value pair
for each append. Then "=" is the only delimeter, and
key values can't have an "=" in them. This is not
what Heidi's original proposal had, and the object
is not a "string" but an array of strings. I'm not
sure what the advantages are vs. a char** approach:
char *infolist[10];
infolist[0] = "my key = my value";
infolist[1] = "my key 2 = my value 2";
etc
And in Fortran:
character*(25) infolist(10)
infolist(1) = ' my key = my value'
infolist(2) = ' my key 2 = my value 2'
etc.
The current proposal in the dynamic chapter (soon to be summarized,
for those of you who weren't at the meeting...) makes use
of the fact that we have key/value pairs, and doesn't
rely on *any* parsing. Unfortunately it then doesn't make
too much sense for the command line.
Personally, I am beginning to think that the current command
line proposal is too hairy and that the right solution is
argv[] in C (but only for arguments, not the original executable,
as PVM does it) and the same in Fortran.
We could do the same for info (a but clumsy, because it
really *is* key/value pairs, not strings) or keep
the current proposal based on key/value.
Finally, we have to make progress. Let's keep that
in mind as we discuss new proposals.
Bill