On Thursday 17 April 2008 19:10:21 Michael G Schwern wrote: > As for why it'll work with TAP, with a few exceptions (exit_status, or > whatever we decide to call it, is currently the only one), diagnostic keys > do not effect test parsing. It's not a show stopper. At worst, a > displayer that has been customized to do something special with a user > defined key might show some odd output. The tests still pass and fail as > before.
Then why is there a problem with reserved keys at all? If TAP v15 adds a new reserved key, anyone who deliberately upgrades may need to modify both the producer and consumer to deal with the collision, if that person even cares. > Prefixing brings an additional problem, how do you tell a TAP displayer to > do anything with all those prefixed keys? Let's say Test::Stuff has > Perl.Test.Stuff-time. So you program your displayer to do something with > Perl.Test.Stuff-time. Now the Test::Thing author thinks that's a neat idea > and adds Perl.Test.Thing-time. So you add in Perl.Test.Thing-time to your > displayer to do the same thing as Perl.Test.Stuff-time. Test::Foo picks up > on it, and you have to add another special case. Test::Bar adds it in, > another special case in your displayer. Another module, add another to the > list. > > You're either going to wind up with a big list of prefixes and keys, which > is annoying work, or you're going to break down and match on /-time$/ and > defeat the point of prefixing. Every part of customizable diagnostics has this problem. > User key collision is not a show stopper for the user. As mentioned above, > at worst a customized TAP displayer shows some confused output for that > key. So it's not urgent that it be worked out. Then why is it urgent to bless a namespace or character set or subset of a character set? You're arguing that collisions don't matter; someone can just write code to fix it, if it matters to them. > The authors of the two colliding producers simply hash it out amongst > themselves. Or they don't, which they won't. Non-executive summary: customizable diagnostic keys aren't that useful, no one's using them, and collisions aren't a problem, so why even bother standardizing them? Here's the question I should have asked much earlier in this thread, before people who want these diagnostic keys started arguing both sides of the question: can anyone provide a real, actually encountered use case where collisions are a real, actually encountered problem, or is this just an attempt to predict the future badly based on what people think might be a problem? (Given that even unstructured diagnostics have never actually appeared in TAP documents before, my guess is "No, everyone's arguing out of ignorance", which seems to me to be a poor way to write a specification, and probably at least half of the reason I keep getting different answers when I ask questions like "Is this useful" and "Is this actually a problem".) -- c
