On 20/07/06, chromatic <[EMAIL PROTECTED]> wrote:
On Thursday 20 July 2006 13:50, Fergal Daly wrote:
> Example code please.
You *quoted* my example code in multiple messages, including this one.
Your example does not produce any incorrect output. Nothing I have
seen in any thread has produced any incorrect output.
Incorrect output is a rumour!
> You're saying there's a situation where using
> $Level produces the incorrect output. I'm saying there isn't.
I don't know what else to call a stack trace that includes irrelevant and
extra information due to an incorrect $Level except "incorrect".
This argument can only hold if $Level is incorrect. Show me a real
life example where this happens.
> Everything I'm saying is based on my opinion that $Level is reliable,
> everything you're saying is based on your opinion that it is not
> reliable.
No, my opinion is that if people don't set $Level appropriately, it's not
reliable. In that case, neither is the stack trace -- because the stack
trace depends on $Level. I consider the stack trace less reliable and
potentially more confusing, because it gives even more information and leaves
it up to the user to pick out which piece of that information is correct, if
any.
Show me a single piece of code on CPAN that doesn't set $Level
correctly and I will show you a bug that should be reported.
$Level should not be touched by a test script author, only by a test
library author so the opportunities for mistakes are small and
testable.
You can give examples where it's correct accidentally, but I don't find "It's
useful sometimes, by luck or accident" a compelling argument for changing the
default behavior.
This is mind boggling, the code I showed is correct. There's no
accident. If I just hit it lucky you'll have no problem showing me
some code that got unlucky.
I'm not changing the default behaviour, I'm adding extra information
and even then it's only when that information is necessary (ie you'll
get one extra line of trace for every layer of subs you have in your
script).
There are already two features that work together to help people diagnose
problems when they use them correctly. Why add a third feature that's
noisier and even less reliable and relies on the correct use of an existing
feature?
You can't use those features to diagnose the problem I set in the
previous mail. It requires 3 pieces of information and you can only
supply 2.
The purpose of $Level and the line reporting is to be able to say "The call to
a test function failed at this point". No less, no more. If people set
$Level properly (and that's a big if), Test::Builder can report this
accurately.
Again, show me code on CPAN that gets it wrong.
The purpose of a test description is to be able to say "The purpose of this
test is...." Test::Builder cannot guess at this.
With the exception of very simple, special purpose test functions such as
isa_ok() and can_ok() and perhaps lives_ok() and dies_ok(), I believe that
knowing the *purpose* of the test is at least as important to debugging the
test as knowing the location of the failure.
Dumping a call stack is, to me, just guessing at the semantics and structure
of the call stack in the hopes that it's useful. I don't think that's a
valid assumption. If $Level is incorrect, who knows whether you're getting
extra, meaningless call frames or too few call frames? It's not obviously
right or wrong, and that's a real problem in testing.
If we still disagree, that's fine; it's probably a philosophical disagreement.
I really don't know how to be more clear in this.
You can stop asserting that $Level is unreliable and show me some
actual code where it outputs the wrong answer. If you show me the
code, I will show you a bug,
F
