Ovid wrote:
> --- Michael G Schwern <[EMAIL PROTECTED]> wrote:
>
>> As Test::More cannot have any dependencies, I'd rather incorporate
>> TAP diagnostic functionality directly into Test::Builder. Besides,
>> spitting out some YAML isn't hard.
>
> It turns out to be a fair bit harder than it appears to be on the
> surface. For example:
>
> my $data = 3;
> my $data = "3";
>
> One is string. One is numeric. As it turns out, it's not easy to find
> a pure perl, core method of doing this but it's really important to get
> this right.
Why? I mean, in some edge cases that's important information to know. Like
once I discovered DBD::mysql was screwing up its bind params when you passed
it a string that had been used as a number, but 99.99% of the time nobody
cares what the internal representation of a scalar is.
Hell, most of the time it doesn't even matter if you're testing using eq or
==. That's why is() works so well.
In fact, I'd argue that since Perl doesn't care (until you get into XS) it
would be wrong to display internal details of a scalar by default.
The baseline diagnostics can just display scalars as scalars and if someone
needs a pile of details they can use a more detailed diagnostic widget.
> Also, if this gets integrated with Test::Builder, where does the YAML
> writer go? I'd hate for yet another YAML writer module to be out
> there.
Writing YAML is pretty easy. I already have most of the logic scattered
around Test::Builder for displaying diagnostics anyway.
What I'll probably wind up doing is make it so Test::Builder hasa
Test::Builder::Diagnostics and then have it choose the appropriate subclass
based on what level of YAML parsing is available. That also allows one to
swap out the Diagnostics object for their own to do whatever level of detail
they like.
Also means you can potentially use Test::Builder::Diagnostics without
Test::Builder.
>> is_new_tap() sounds more like its testing a TAP stream, not the TAP
>> harness.
>>
>> "new", like "fast" or "lite", is one of those subjective,
>> context-sensitive
>> adjectives that make for a bad routine name.
>>
>> How about something more direct: harness_supports_tap_diagnostics();
>
> I thought about something more verbose, but I confess that I like to
> avoid longer function names. They irritate people. Still, maybe it's
> worth it in this case.
I don't think it is. It's not like folks are going to be calling this
function all over their code.
>>> ---
>>> executable: perl
>>> inc:
>>> - lib
>>> - t/lib
>>> - /System/Library/Perl/5.8.6/darwin-thread-multi-2level
*snip*
>>> Some of that is Perl-specific and therefore is wrong. However, it
>> can
>>> be very useful for debugging information.
>> It's a module for TAP producers so it can go ahead and produce Perl
>> specific stuff. Non-perl TAP readers will simply ignore
>
> Actually, I think it would be better if there were a 'perl' key which
> keeps perl-specific information grouped together.
Fair nuff.
>> A timestamp would be helpful. The ISO 8601 is easy to machine parse
>> but a little hard on humans.
>>
>> timestamp: 2007-09-01T07:09:54-0700
>>
>> RFC 3339 is a little easier to read. I'm inclined towards this.
>>
>> timestamp: 2007-09-01 07:09:54-0700
>
> Agreed. However, I don't know enough about the impact of having that
> 'T' there and not. I'd prefer one of the first two options rather than
> the third.
The first is a single ISO 8601 datetime. The latter is an ISO 8601 date and
an ISO 8601 time separated by a space. Two data fields instead of one. So
it's all kosher, we just have to specify that's what we're doing.
tapdate = isodate " " isotime
--
The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.
