On 7/3/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> How about
>
> my $a = [];
> my $b = [];
> my $s = sub { $_[0] == $a; }
> is_deeply($a, $b); # passes
> is_deeply($s->($a), $s->($b)); # fails
Near the top of the last mail I said "there is nothing you can do to
tell them apart (except actually looking at refaddrs)" which is
bascially what you've done here. In fairness when I originally allowed
refaddr comparisons I didn't do it clearly enough. What I said was
"the only operations that needs to be banned are those which look at
the address of a reference (except to compare it to the address of
another reference)." What I forgot to say was "another reference
within the same structure".
Again it comes down to my thinking of these 2 structures as 2 separate
things maybe even on 2 separate computers (or produced by 2 differrent
programs - perhaps before and after a change) and you want to know
whether they have produced answers which are completely
interchangeable. When you think in those terms, comparing addresses
from one structure to those in the other makes no sense.
You can say I'm moving the goal posts but if you allow comparisons
like that, the whole concept is trivially broken
# $a and $b are anything that will pass
is_deeply($a, $b); # pass
is_deeply($a == $a, $b == $a); # fail
no need to introduce subs at all.
I could have banned all refaddr operations but that's not necessary,
unfortunately I was not clear enough on when they are acceptable. If
you think in terms of parallel processes where is_deeply() is
something that can see the data in both processes but nothing else is
shared then it's more clear which refaddr operations make sense and
which don't.
Anyway...
Do you agree that there's a difference between [ [], [] ] and [ ([]) x 2 ]?
Do you agree that it's possible to detect this difference?
Do you agree that it's possible to detect that 2 structures have no
such difference?
Do you agree that this differrence can be a source of bugs?
> > The bug might depend on the data so although the code might be
> > identical on both sides, the code-path might be different.
>
> If you're saying the comparison function might be buggy, ok sure.
> However, there are cases where objects in a class can have variant
> representations and still be observationally the same (assuming the user
> respects some abstraction boundary). In this case, a comparison
> function for that class is appropriate.
Fair enough, I suppose elsewhere you have tested this comparison
function. However is_deeply is unlikely to ever start behaving
differently for different classes, it ws brought way back and is the
reason Test::Deep was written,
F
