On Tue, Mar 06, 2001 at 11:59:40AM +0000, Piers Cawley wrote:
> Matthew Astley <[EMAIL PROTECTED]> writes:
[comparisons]
> I'd definitely rather do the Right Thing. And the Right Thing is to
> use the appropriate comparators.
Exactly. It's inconvenient, but Right.
> > 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];
> ...
> }
Well it's not much use in do_assert, although if it were in the
opposite one then it would make sense to be symmetrical.
> 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.
I'm inclined to give sort-blocks separate namespace, and this is a
good reason. It doesn't take too much sugar...
$self->assert(new Test::Unit::Assertion::SortBlock sub { $a cmp $b },
also the arguments can then be tailored, so while
, $foo, $bar)
would be quite restrictive,
, [$foo, $bar], [$wibble, $spong])
would be quite powerful. Mixing the two would be confusing!
(spot the solution looking for a problem again, though)
> > 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...
You code can still die ... ahhh. I've been doing quite a lot of "eval
this code and make sure it dies with an error matching qr//"
I suspect this, like Adam says, is a time to roll my own assertion
classes outside the T:U namespace.
> > 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");
> }
I think I was after
sub T::U::Assertion::NRegexp::do_failif {
the way I was thinki ^ ng the two would be alternatives. If you pass a
Regexp to assert, how does it know whether that's positive or
negative?
Problem is, a Regexp seems to be a blessed thingie already, but I find
any module file or comprehensive docs. Not that I looked _very_ hard.
> 'failif' or 'nassert'?
or 'tressa'? Or is that too FORTRAN? (FORTRAN? I first bumped into
that with shell script...)
> 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.
Unexpectedly returned true .. your average error message is 'true', so
this would actually suit me much better.
However, last time I suggested such a feature you reminded me that the
package can 'die "foo"' just as well as 'return "foo"'.
> > 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.
Oh absolutely, but as a lazy user I'd rather install one package than
two. <shrug>
Matthew #8-)
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
