Matthew Astley <[EMAIL PROTECTED]> writes:
> (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).
I'd definitely rather do the Right Thing. And the Right Thing is to
use the appropriate comparators. Until Perl's strings and numbers
become first class objects. At which point Perl will probably be
Ruby.
> >> $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".
Hmm... can't see anything wrong with doing:
T:U:A:CodeRef::do_assert {
my $self = shift;
local($a, $b) = @_[0,1];
...
}
Which would mean that the kind of blocks that sort takes would work
with the CodeRef assertions. But that could be taken to be rather more
DWIM magic than is good for a framework. Especially one that's
claiming to be all grown up and OO.
>
> Is it too complicated to allow our coderef objects to implement a
> "do_failif" method instead of the "do_assert" ?
The problem I see with 'do_failif' and an associated 'failif'
mechanism is that of deriving meaningful failure messages for
arbitrary coderefs. Not that this would necessarily be a problem...
> I think if we could generalise this nicely it would also solve the
> negative regexps problem.
Good point.
sub T::U::Assertion::Regexp::do_failif {
my $self = shift;
my $target = shift;
$target !~ /$$self/ or
$self->fail("'$target' matched /$$self/ unexpectedly\n");
}
'failif' or 'nassert'?
Hmm... getting meaningful error messages for coderefs is still tricky,
but then it was never actively easy and the 'this sub with these
arguments unexpectly returned true' style of default error message
should be enough for the user to work out what's going on.
> 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.
The point of B::Deparse is that it's supposed to be useful even if
you're *not* messing about with the internals of Test::Unit.
--
Piers
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
