On Tue, Sep 09, 2003 at 06:09:16PM +0100, Fergal Daly wrote:
> But it doesn't fail, it never has failed and it was never intended to fail.
> is_deeply is specifically for looking at and descending into the structure of
> it's arguments, otherwise what's the point? Where's the "deep"ness?
I don't think it should pass. It's relying on a feature of the way
Perl's OO was hacked together.
> > is_deeply should be completely useless for testing the innards
> > of *any* object. It's not what it should be for.
> 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.
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.
> It's about being deep, not deep sometimes but stringy other times and the test
> writer having no control over when it this might happen.
Only to the extent that you have no control over how 'eq' does its
magic. This is perl, after all.
And if you really want to test the innards of an object then you should
be explicitly breaking the encapsulation:
is_deeply { %$obj }, { name => "Fred", address => "..." };
I'll maintain that
is_deeply $obj, { name => "Fred" ... }
should fail.
Now, I accept that it doesn't at the minute, and if people are relying
on it, then there's nothing much that can be done about that.
I think there are too many conflicting interpretations of what is_deeply
should do, mostly seeming to stem from its ambiguous documentation.
Rather than trying to salvage it at this stage, I'd suggest adding new
methods that do each thing, and eventually deprecating is_deeply.
Tony
