On Wed, May 26, 2010 at 11:09:49PM -0600, David Green wrote: : On 2010-05-26, at 1:53 am, Moritz Lenz wrote: : >> The tests might need fixing too, since I'm not sure whether eqv (as used by is_deeply) would cover that, or whether it would take a separate test in bool context. : > : > probably the latter. : : I guess it would have to -- that is, "but" creates an ad-hoc new class, : so even if you take two identical objects and "but" them the same way, : there's probably no good way that eqv can tell they are the same. : At best, it could know that one or both of its operands had been : "tampered with", and report false. : : (If you wanted to manipulate two or more objects the same way, then : you'd have to make a new class with the appropriate overloaded methods : and then eqv could compare my NumButFalse $n1 to my NumButFalse $n2.) : : In order to compare two objects that were created and modified on : the fly, you could see what roles/methods they actually have, and : compare the values in whatever way is suitable. I guess you could : see whether an object has extra roles with something like: : : all($x.roles) === all ($x.WHAT.roles) : : Still, it's important to be able to tell whether two things can be : expected to work the same way, so perhaps there can be an adverb for : eqv that says to pay attention to ad-hoc changes (or vice versa). : Since 'but' is special syntax, maybe there's even a way to compare : snapshots of all the types that were 'but'ed in to the base type, : but I don't know how feasible that is.
Or going the other direction, perhaps we're missing a primitive that can produce a data structure with the type information stripped, and then eqv might be able to determine structural equivalence between two canonicalized values. Larry
