[tap-l] User Supplied YAML Diagnostic Keys: Descriptive Version
Smylers at stripey.com
Sat Apr 19 17:24:46 UTC 2008
Michael G Schwern writes:
> David E. Wheeler wrote:
> > On Apr 18, 2008, at 10:50, chromatic wrote:
> > > My argument was complex: solve the real problem or don't solve it.
> > > The in between position is silly and won't make anyone happy.
> > Yes. The choices, as I see them, are:
> > 1. Do we start out conservative, and loosen things up as the cow
> > paths indicate (Ovid's position)?
An example of this would be saying:
We promise that all future 'official' keys will start with a
lower-case letter. It is prohibited for you to start an in-house key
you create with a lower-case letter.
> > 2. Do we start out liberal, allowing anything, and formalize
> > whatever turns up in the cow paths (what I'm now suggesting)?
An example of this could be saying:
All current 'official' keys are lower-case (and start with a letter)
and we expect future ones will be as well. If you choose to create an
in-house key which starts with a lower-case letter then you risk a
clash in future should we happen to introduce a key with that name.
In practice, what's the difference between those two?
The first is apparently stricter, but the prohibition can't actually be
inforced: if a user chooses to ignore it then we can't send him to
prison or anything; it's just that there's a (small) chance of his
system later failing.
Similarly if the future Tap maintainers bizarrely do create a key named
in some other way, whether they are breaking a promise or a mere
expectation doesn't make any difference: it isn't like users can sue
over a broken promise.
So since choice 1 can't be enforced, it seems to behave exactly like
choice 2 anyway.
> The prefixing solution sucks, but it's all we have... and that's a bad
> place to be. Rather than arguing about a sucky solution, does anyone
> have another solution to offer?
In practice users can name keys however they want. Namespace clashes
will be a bigger issue for some users than others. Issue advice on how
to mitigate the problem and let users choose whether to follow it:
It's possible that a key you pick will also be used by somebody else
for a different purpose, which could cause problems if your systems
later get used together. You can reduce the risk of name clashes by
starting all your keys with a standard prefix or your organization or
project name (or something else likely to be unique).
More information about the tap-l