Re: attributes, possible interface

You win .. but we have a few topics mixed here.

I was looking at the code to see if something is there that can be
reused.  ...  not really.  PARAM_LIST is numeric.

So how about a new class ...  ATTRIBUTES, or ATTRIBUTE_LIST.

1. Internal storage?
Need to keep overhead down when it is not used.  That's why I said
string.  It's everywhere, and not used most of the time.  Shell
environment variables store the whole thing, all of them, as one string.
Look at #2 before deciding.

2. Access 
I think all we need is set by name and get by name (subscript).
There is no need for by index.

Error handling ..  Set will always succeed, possibly replacing.  Get
returns empty string if it isn't there.

back to 1 ..
If all access is through access functions, it can be changed later.
Efficiency of storage space is more important than speed.  The number
of attributes set is small.  So linear search is good.  Hashed is not.

If storage is a simple string, convert to CS which has scan which can
easily extract the one you are looking for.  The map is probably
easiest.  I am not sure about empty overhead.