On 7/2/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote: > On Sat, Jul 02, 2005 at 08:55:34AM +0200, demerphq wrote: > > The entire basis of computer science is based around the idea that if > > you do the same operation to two items that are the same the end > > result is the same. > > 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. > Otherwise, one will always be able to observe differences between them, > and in Perl it's particularly easy: > > $a = []; > $b = []; > is_deeply($a, $b); # you say should pass > $a = "$a"; # doing the same operation > $b = "$b"; $ to $a and $b > is_deeply($a, $b); # fails > > 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. > So neither position is "right", though either could be useful in a > particular case. I agree with you (yves) that considering aliases > within the objects being compared could be useful. > I also think that > any such comparison should allow objects to override the comparison. You need to be very careful there. Allowing objects on the "expected" side to control the comparison is ok but If you allow the data that you are testing to control it then your test is effectively meaningless. When testing you have to assume there are bugs in what you are testing (otherwise why test it?). So you definitely don't want to hand control over to something which you already suspect to be buggy because it might say "pass" for the wrong reasons. For example, you might think you checked that something was the string "Bob" when actually it was a buggy object that overloaded string comparison to always return true and in fact will look like "Alice" if you ever stringify it. > Finally, I think that comparing functions (which started this > discussion) is insane! :) F
