(Sorry for the delay, I got swamped. XP and hard deadlines don't seem
to mix too well. I'm likely to stay swamped for a while too)
On Mon, Mar 05, 2001 at 03:38:45PM +0000, Adam Spiers wrote:
> Piers Cawley ([EMAIL PROTECTED]) wrote:
> > Adam Spiers <[EMAIL PROTECTED]> writes:
> print equal('1e1', '10') ? 'equal' : 'not equal', "\n";
> print equal( 1e1 , 10 ) ? 'equal' : 'not equal', "\n";
>
> does the right thing.
What about rounding errors? Or when 'use integer' is in effect? (Not
that I've thought about these or tried them).
>> $str_match = sub { $_[0] eq $_[1] or die "Expected $_[0], got $_[1]\n" }
>> $numeric = sub { $_[0] == $_[1] or die "Expected $_[0], got $_[1]\n" }
>>
>> $self->assert($str_match, "Foo", "Bar");
>> $self->assert($numeric, 10, 11);
>>
>> Simple, functional, doesn't add any more methods to Test::Unit::Assert
>> and friends. Which is nice.
>
> Ahhhh. Now that *is* nice. You should have shown it earlier - it
> persuaded me almost instantly :-)
Yes, that does it for me too, except my next reaction was "Ah, so we
can reuse the routines that 'sort' takes?" .. then "oh, the sense is
wrong".
Is it too complicated to allow our coderef objects to implement a
"do_failif" method instead of the "do_assert" ?
I think if we could generalise this nicely it would also solve the
negative regexps problem.
As for B::Deparse, I probably wouldn't want to bother installing if I
weren't messing with T:U itself, so thanks for making it optional.
Matthew #8-)
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
