On Wed, 21 Jul 2004 14:51:13 -0400, Ricardo SIGNES <[EMAIL PROTECTED]> wrote: > I was going nuts recently, trying to figure out why I couldn't use > is_deeply to compare objects. I've finally determined that it's only an > issue (as far as I see) when comparing objects that overload > dereferencing to their implementation type. > > The attached code should fail all three tests; at no point are the two > structures identical. Instead, the third test -- when the structures > are blessed into an implementation-type overloaded class -- passes. > > This should be simple-ish to fix, I'd think. > > 1. two objects are different if their implementation types differ > 2. two objects are different if their blessed-into-temp-class structures > differ > 3. otherwise two objects are the same > > So, given two Garbage::Overloaded=HASH objects, we'd bless them into > Test::More::TempClass and then compare those. > > Thoughts?
Something similar to this came up before. The upshot is that I reaffirmed the implicit choices made in is_deeply's design: It does not attempt to pierce overloading. Originally this came up in the context of trying to compare Class::DBI objects which overload stringification. Given that choice, obj_deep.t is working correctly. The choice was made to preserve the encapsulation that overloading gives. A clear example is date objects. A function which returns a date as a string and a date as an overloaded date object should remain indistinguishable. I felt it was more important to preserve this important aspect of blackbox testing than the glassbox technique of examining an object's internals. There are two ways around this. Supply a private _guts() method to get at the object's internals or use the much more flexible Test::Deep. I'll make a note to clarify the overloading situation in the docs.
