[960] Fault unknown TAP tokens in strict mode (V13+)
Eric Wilhelm
scratchcomputing at gmail.com
Sun Feb 17 18:55:56 UTC 2008
# from Andy Armstrong
# on Sunday 17 February 2008 09:39:
>On 16 Feb 2008, at 18:15, Eric Wilhelm wrote:
>> All new tap would have a known prefix? That is, a v13+ parser
>> should be
>> able to say "that is a TAP keyword, but I don't support it."
>
>Kind of restrictive, no?
Yeah. Your suggestion of just disabling strict if $version > $supported
is probably the way to go.
>> I like the idea of TAP being stricter, but I'm not sure if it is
>> warranted or desirable.
>
>I can't parse that :) Why do you like it then?
uncertainty ne dislike ;-)
The benefit of stricture is less ambiguity. The drawback is that (1)
cross-version and (2) intra-tool version compatibility is more
difficult.
If we only enable stricture for known versions, then (1) is solved
(solved in terms of stricture -- actual forward version compatibility
depends on a lot of things.)
Without some kind of prefix in front of all tap, (2) requires the
emitter to exert itself a bit more if any garbage is to be passed thru
(e.g. tie STDOUT or something.) It could declare e.g. 'v13 strict' at
the beginning, but needs to then have begin/end garbage directives and
e.g. print_garbage() functions. This will, of course, also have the
same issues as xml CDATA in that the end directive could appear in the
output.
But, CORE::GLOBAL::print is non-replaceable, so a nice DWIM
implementation in the emitter isn't going to be easy, right? Given
that the call to print could happen anywhere, I guess the use-cases are
going to be either "strict on" or "strict off". So, that simplifies
the implementation to just a declaration in the header?
Unfortunately, making Test::More default to strict will break CPAN, and
typing "use Test::More strict => 'no_plan'" will be tedious, so I would
like a Test::Smore. :-D
--Eric
--
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
More information about the tapx-dev
mailing list