On 7/3/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote: > On Sat, Jul 02, 2005 at 07:34:47PM +0100, Fergal Daly wrote: > > On 7/2/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote: > > > Citing "computer science" as the basis of your position is just too > > > much. The "computer science" answer to the comparison of references is > > > that they are equal if and only if they are the same reference. > > > > Actually what Yves wants is known a testing if 2 structures are > > bisimulable in computer science. > > Can you give me a hint as to the difference in a language like Perl?
When they are the same reference they are the same reference (can't think of any other way of saying it). When they are bisimulable, they're not the same reference but there is nothing you can do to tell them apart (except actually looking at refaddrs). Obviously if you change 1 of them you can tell them apart but if you make the same change to the other they become indistinguishable. http://en.wikipedia.org/wiki/Bisimulation has some unhelpful definitions. At it's simplest it's being able to tell the difference between 2 pointers to distinct empty arrays and 2 pointers to the same empty array. It's an important difference. > > > That this is just one example, and if you try to worm out by saying > > > "such-and-such operation is not allowed", I'll find you another. > > > > I'm not sure you will. As long as this is_deeply looks inside the > > objects of tied and overloaded refsthen 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). If you > > exclude those operations (which are fairly useless outside of > > debugging) then I don't think anything else goes wrong. > > What about > > my $x = []; > my $a = [$x, []]; > my $b = [[], $x] > is_deeply($a, $b); # passes > $a->[0][0] = 1; > $b->[0][0] = 1; > is_deeply($a, $b); # fails The first call is actually a fail. Let's give them names $x = []; $y = []; $z = [] $a = [$x, $y] $b = [$z, $x] now it's easier to see, comparing the 0th elements will pair $x with $z and comparing the 1st elements will fail because $x has already been paired with $z so can't be paired with $y. However it raises an important issue that I hadn't considered. I (and I think Yves) had always been thinking in terms of 2 structures that had been produced independently, that is nothing in $a can be part of $b but that's not realistic. In real test scripts, chunks of the expected and the received values will be shared. The solution there is that whenever a ref appears on both sides it can only match up with itself. So I'd even say that is_deeply( [$x, $y], [$y, $x]); should fail. > I was thinking that the comparison function would be a class method that > would be called after verifying that two references point to objects in > the same class. I think that should be safe enough. 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 realy want deep testing with custom tests that can apply deep inside Test::Deep, already does it, F