----- Original Message ----
> From: Moritz Lenz <mor...@faui2k3.org>
> * the word 'is' is overloaded in Perl 6
> * if we export subs is() and ok(), we clutter the
> namespace with subs with short names
> * is() is rather imprecise; it doesn't say *how*
> things are compared.
<snip>
> So Larry and Patrick developed the idea of creating an
> adverb on the test operator instead:
>
> $x == 1e5 :ok('the :ok makes this is a test');
This may all be irrelevant, but I'm tossing it out here in case anyone thinks
of how it might impact things.
I'm not entire certain how I feel about this yet, but I love the core concept
of making testing a first class feature (well, duh ... of course I would say
that :)
I'd like for this to be thought through really carefully lest we create an
interesting idea which is hampered by its implementation. Specifically, I'm
concerned about diagnostics. What we'd ultimately love to have in TAP is some
way of improving diagnostics (pseudo-TAP).
is 3,3 'constants are constants;
# ok 1 - constants are constants
# have: 3
# want: 3
Now we have a curious situation:
multisub foo(Str $bar);
multisub foo(Int $bar);
If we're testing what we should pass to &foo:
is 3,"3" 'constants are constants;
# ok 1 - constants are constants
# have: 3
# want: "3"
Integration tests will still do OK, but unit tests may have issues and this
could be an expectation violation. What does it mean that the string 3 eq the
integer 3?
Worse:
my $bar = 284;
ok $bar, '$bar should be true';
# ok 1 - $bar should be true
# have: 284
# want: True
That can also look a bit strange, particularly if someone is coming from a
different language background.
How would this new system handle diagnostic information? One thing which might
mitigate this is something we've wanted in newer versions of TAP:
my $bar = 284;
ok $bar, '$bar should be true';
# ok 1 - $bar should be true
# test: ok $bar, '$bar should be true';
# have: 284
# want: True
By letting programmers see the exact line of code for the test, the type
information *might* not be as important. I'm unsure.
One possibility is to look at the &Test::More::cmp_ok function:
$ perl -MTest::Most=no_plan -e 'cmp_ok 3, "==","2"'
not ok 1
# Failed test at -e line 1.
# got: 3
# expected: 2
1..1
If you change "2" to "3", the test still passes, but we could force it to not
pass unless eq is passed in as the second argument. Then we could have the
following diagnostics:
perl6 $ perl -MTest::Most=no_plan -e 'cmp_ok 3, "eq","3"'
not ok 1
# have: 3
# test: eq
# want: "3"
1..1
And then it's crystal clear why it failed.
Cheers,
Ovid
