On Fri, 2005-09-30 at 19:20 -0700, Michael G Schwern wrote: > There's not really a mistake, more that if a given reference is overloaded > in several ways its not possible for Test::More to guess which one is the > canonical representation. Should this blessed, string and array overloaded > hash ref (I'm going to assume its a hash ref) be treated as an array ref or a > hash ref or a string? Can't tell. Test::More prefers strings since its > the most common type of overloading.
Ok. I was confused because it used to work in the past. I think is_deeply() used to use the 'eq' operator on objects that overload it. Glib::Flags deliberately overloaded 'eq' for Test::More, if I remember correctly. > And, umm, I'd think a bit about the wisdom of having something which is > both string and array overloaded. We did. I think in makes perfect sense in Glib::Flags' case: Glib::Flags represents C flags as an array reference. Whenever it is passed around, it gets interpreted as an array reference. Only when the programmer tries to print it, the string overloading joins in and turns the array reference into something legible: [ value-one value-two ... ] Glib::Flags also overloads quite a few other operators to allow doing flags arithmetic like OR'ing or AND'ing in other flags values in a Perl'ish way. -- Bye, -Torsten
