On Tuesday 09 September 2003 18:40, Tony Bowden wrote: > > It's incredibly useful for testing the innards of objects, I think that's what > > people use it for. > > I still don't think it should be. An object is not a hashref or a > listref. It might happen to be implemented by blessing a hashref or a > listref, but that doesn't make it *be* one.
>From what he has said and from the internals, I think that's what Michael intended it for. > Coupled with the fact that objects can easily pretend that it has things > that it doesn't or have lazy loading of its data members or the like, > checking what happens to be stored in the hashref, listref whatever is > almost always going to be a Bad Thing. If you're the person writing the objects, it can be useful. Even if you aren't, it's still useful. Where I've used like that is in a parser. I send a string to the parser and it gives me a tree of objects. I also build the object tree by hand just by using ->new and accessor methods. Then I compare them to make sure that the parser built the object tree correctly. In that case the test script has no knowledge of the internal structure of the objects. It's just testing that my automated tree builder built the objects it was supposed to. > I think there are too many conflicting interpretations of what is_deeply > should do, mostly seeming to stem from its ambiguous documentation. If there's one thing we agree on, that's it. > Rather than trying to salvage it at this stage, I'd suggest adding new > methods that do each thing, and eventually deprecating is_deeply. Test::Deep can be as deep or as shallow as you tell it, as stringy, nummy or as ignore-overloady as you tell it and it will do these things exactly where you tell it to do them and nowhere else. It does everything except make the .t http://www.esatclear.ie/~fergal/sounds/surp.wav :-) F
