Grokbase Groups Perl qa April 2008

--- Steffen Schwigon wrote:

A see. But TAP isn't SMTP or HTTP and an explicit prefix matches the
"be descriptive" of Schwern, doesn't it?

And we are talking about the diagnostics part, which is primarily for
the user, so the rules are reversed there.
There are two goals we want:

1. Make it as human-readable as possible.
2. Maximize flexibility.

As for human-readable, consider these:

tap-have: 4
tap-want: 5

have: 4
want: 5

(And remember that there could be plenty of other diagnostics in

I think the second is more readable, but that's a bit subjective.
Still, the idea has merit because it addresses my concern below.

Regarding maximum flexibility, Adrian Howard has already pointed out
that if we restrict people to 'X-', then we can always be more
permissive in the future. If we open it up to just about anything they
want and it turns out to be a mistake, we could easily be backed into a
corner. Why on earth would we *deliberately* choose an option that we
know might be problematic, particularly when someone's non-unicode
aware language might get confused about what is and isn't lower-case?

It doesn't hurt us to play it safe with such a major change. It
*might* hurt us to make a major change when we already KNOW that
potential problems are out there. We're not talking about a minor
utility that only a handful of people would use. We're talking about
playing fast and loose with core infrastructure tool that many people
are dependent on.

On an implementation detail, parsers will need to differentiate between
TAP standard keys an user-supplied keys. Right now it's simple in

if ( $key =~ /^[[:lower:]]/ ) {
# internal key

Not all languages make it that easy. Also -- I don't know the
specifics here -- are we now going to have to require 'encoding'
meta-information in TAP to make sure that the above regex works?


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 48 | next ›
Discussion Overview
groupqa @
postedApr 11, '08 at 11:01a
activeApr 19, '08 at 4:24p



site design / logo © 2021 Grokbase