Ovid wrote:
> Regarding the disadvantages:
>> However nothing in life is free, we pay for it with a
>> few disadvantages:
>> * We nearly double the number of built-in operators
>>    by adding an :ok multi
> Yes, but conceptually this will be transparent to the end user, right?  
> They'll just know that they can add :ok to operators.  They'll mentally have 
> one extra piece of information, not twice as many.


>> * We force implementors to handle operator adverbs
>>    and named arguments very early in their progress
>>    (don't know how easy or hard that is)
> This might be a problem.  After my (now possibly moot) rewrite of Test.pm was 
> finished, my plan was to write a basic Test.pm which required as few features 
> as needed but still allowed the spectests to run.  Then you simply provide 
> language developers a list of features they need to implement to run the test 
> suite.  Adding operator adverbs to the mix means a lot of rewriting of tests.
> Alternatively, we can say "you don't need these at first" and Test.pm is 
> merely a older way of running tests.  It still remains a valid alternative 
> and new implementers don't need to worry about adverbs. 

But if the spectests are re-written in terms of adverbs, a compiler
can't use them without adverbs. If not they are not re-written, there's
no point in introducing the syntax.

>> * Testing of operators becomes somewhat clumsy. If you
>> * want to test infix:<==>, you won't write
>>    '2 == 2 :ok("== works")', because you test a
>>    different multi there. Instead you'd have to write
>>    something like '?(2 == 2) :ok("== works")', where
>>    :ok is an adverb on prefix:.
> Bad:
>   2==2 :ok("== works");
> Good:
>  ?(2==2) :ok("== works");
> I don't relish explaining, over and over again, why the first is bad and the 
> second is good.  That being said, if this is only used for internals tests, 
> is this likely going to be exposed?

This will only be a FAQ for the contributors of the official Test suite,
and for people who write and test their own boolean operators. I guess
we can live with that.

All other people will assume that the operators already work.

>> So I'd like to hear your opinions: do you think
>> adverb-based testing is a good idea? If you don't like
>> it, do you see any other good way to tackle the
>> problems I mentioned above?
> So how would the following work?
>   can_ok
>   lives_ok
>   throws_ok
>   isa_ok
>   is_deeply

They would remain subs (unless somebody has a much better idea).

> And so on?  Sure, I can write extensions for this, but they're so common that 
> it seems a shame to not have them built-in, but what operator would they hook 
> to?
> Also, if we're going to go whole hog on this, then may I suggest a "tests" or 
> "test" keyword?  We might have :ok embedded in our code, in which case 
> running multiple sections of code might have multiple sections with :ok.  How 
> do test numbers work?  When Foo.pm calls Bar.pm calls Baz.pm and they all use 
> :ok, we may not know how many tests we have, so these might get handled 
> different from something like this:
>   test Unit::Customer plan 3 {
>       use Customer;
>       my Customer $cust .= new( :fname<Billy>, :lname<Bob> );
>       $cust.fname eq 'Billy' :ok<fname should match>;
>       # plan assumes 2 referrals
>       # won't work because we can't interpolate?
>       for $cust.referrals -> $ref_cust {
>           $ref_cust.referrer === $cust :ok<{$ref_cust.name} should have 
> correct referrer>;
>       }
>   }
> With a scheme like this, we can separate tests explicitly written by 
> programmers for testing and those which are embedded.  If the &referrals 
> method has :ok in it, this shouldn't impact the overall plan, right?
> Side note: for the desugar, I'd still prefer we go with 'have/want' instead 
> of 'got/expected'.  We've been wanting to do this with TAP for a while. It 
> reads well and also aligns nicely for fixed-width fonts.

I'll think a bit more about these points.


Reply via email to