On Wed, Jan 21, 2009 at 13:44, Ovid
<publiustemp-perl6langua...@yahoo.com> wrote:
> ----- 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.
>
since the :ok adverb is modifying the operator, perl knows what kind
of comparison is being attempted, and can automatically give smart
diagnostics. this point was taken into consideration when the
adverbial test syntax was originally designed. some examples of perl 6
tests using adverbial notation:
plan *;
3 === "3" :ok('int constant is equivalent to string constant integer');
3 !~~ "3" :ok('int constant smartmatch to string constant integer')
my $x = 284;
+$x == 284 :ok('$x is 284');
?$x :ok('$x is True');
there will no longer be ok() and is() functions, so although is() is
still a floor wax and a dessert topping, it has nothing to do with
testing. the comparisons are now explicit, so the intent of the test
isn't hidden behind a friendly-looking but difficult to debug function
like is().
~jerry
