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

Reply via email to