On Fri, 2006-10-20 at 13:41 +0100, Nigel Swinson wrote:
I disagree. I think encoded-octet and variables should be independent
extensions.
I agree
ditto.
That's 2:1 now saying we need a new extension to evaluate
"${hex:${variable}}".
Anybody else?
I would want ${hex:${variable}} to be a syntax error if "hex" was
requir()ed, and valid if variables was require()ed and "hex" was not.
I don't see a need for recursive evaluation. I'm used to one pass,
just like dequoting. At the moment I can't think of any recursive
string expansion out there... Instead put your hex into ${variable}
when constructing it.
this implies variables should evaluated first.
I must admit I envisaged a single pass (concurrent evaluation) with no
backtracking, which means
"${hex:${var}}" -> "${hex:VALUE}"
"${v${hex:61}}" -> "${var}"
but I now think it makes more sense to order them explicitly. it makes
most sense to have encoded-character evaluated before variables (since
it's defined in the base spec), but it's probably more useful to do
variables before encoded-characters, as Nigel demonstrates.
oh. I just realised my suggestion has the same shortcoming as the
variables syntax: it won't raise syntax errors, since it only matches
well-formed character sequences. I may have a look at fixing that
during the weekend.
--
Kjetil T.