in reply to Re^5: Recursively traverse two data structures and test for match
in thread Recursively traverse two data structures and test for match
But I don't think that's a problem. You're doing an "out of band" test, you should have to jump through hoops. Whereas if, in the course of an application, I want to know, "are these two widgets equal?" I should depend on any overloaded equality ops to do the right thing, not to second-guess what the right thing should be.
|
Re^7: Recursively traverse two data structures and test for match
by diotalevi (Canon) on May 23, 2005 at 15:56 UTC
|
My t/whatever.t script using Test::More hardly counts as "in the normal course of an application." This is an environment where you really do want such things to happen, if that's what you intend. Testing environments are abnormal environments and this is a case where it matters that its treated as such. | [reply] |
|
|
So you don't expect anyone to ever test their modules against overloaded input? I disagree that comparisons should default to being x-ray comparisons just because they are part of a test module. I'm more likely to test that the output from two invocations produce the same apparent output than that they result in identical internal structures. The former is an important aspect of a module, while the latter shouldn't really matter.
Update: In a private message, diotalevi notes that he meant that the test should usually be normal but that there should be a way to do the x-ray test. My reponse is that to do the x-ray test you temporarilly unbless the overloaded items, but I'm shocked to see that Scalar::Util doesn't have unbless(). There is a non-core module, Acme::Damn, but that nearly doesn't solve the problem (being non-core and also XS and further Acme::). But I suspect that temporarilly blessing into a non-overloaded package would be a "fix", but I haven't tested such.
| [reply] |
|
|
Blessing into a non-overloaded package is the official way to get around such difficulties. 'Does::Not::Exist' is a popular one.
My problem was that with a deeply nested data structure, I'd have to walk the entire thing first, find all the objects blessed into the overloaded class, and rebless them prior to asking Test::More to compare the structures. I have the opinion that its all that structure walking that prompted me to use is_deeply() in the first place but to have it fail to work because I couldn't convince it to ignore overloading was a disappointment.
| [reply] |