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
: > 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.