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