On Apr 11, 2008, at 03:59, Michael G Schwern wrote:
Quite rapidly everyone shifted over to thinking that we should only
allow
"X-foo" for user keys because it's unambiguous. Then we don't have
to worry
about characters that don't have an up/down-case concept. And we
can eyeball
a user vs reserved key slip. And it looks like mail headers and
we're all
used to reading mail headers. And we can always allow a wider use
later.
Etc...
What about reserving only lower-case ASCII for internal use, and
anything else is fair game? That's unambiguous and pretty easy to
enforce, plus is close to your original proposal, since 9x% of the
time, people will just use uppercase ASCII anyway.
Seems like a fine solution. Everyone agreed but me. It seemed like
I was
just being a sore loser, and maybe I am, but I don't often dig in my
heels
unless I think it's really, really important to get it right. The
last time
that happened was the business about Test::Harness 3 merging STDOUT
and STDERR
which took months to resolve.
It seems unnecessarily limiting to me.
I don't really care so much about doing "Foo" or "X-Foo". It's all an
aesthetic choice. What worries me is that we're encoding an
aesthetic choice
at all. That we're proscribing behaviors because we think it might
be ugly or
hard to read or harmful or stupid or redundant or difficult to
specify. We
have too narrow a vision to make that decision. All we can
truthfully say
about the future is that our predictions will be wrong. If we
proscribe what
we think might be bad, because we're going to be wrong, we also
proscribe what
might be good. If we proscribe what is bad now, because things
change we also
proscribe what might be good later.
I agree. I think that the spec should actually limit a very small
subset of a universe of options rather than limit the consumers of
that spec to a small subset. Make the spec have to think harder about
what's allowed.
This is why we should be descriptive instead of proscriptive.
Descriptive
means to specify only what you need and leave the rest open. It
provides a
playground for users to fool around in and try things out that we'd
never have
thought of. It provides the cracks into which really clever people
can wedge
radical new ideas to advance in wild new directions. It's the
flexibility
that allows a language to survive for 20 years and all the
unpredictable
changes that come. Perl survives and grows that way, TAP should too.
Amen to that.
Nice post, Schwern.
Best,
David
