On Tue, Sep 09, 2003 at 05:49:47PM +0100, Fergal Daly wrote:
> On Tuesday 09 September 2003 15:29, Tony Bowden wrote:
> > my $str1 = MyString->new("foo", "bar");
> > my $str2 = MyOtherString->new("foo", "baz");
>
> Now they _do_ differ by more than just class and it should be a fail, although
> I must admit that even with the current is_deeply it will be a pass. I
> consider that a bug and it's something I avoided in Test::Deep by using
> Scalar::Util::refaddr, I just never backported that to Test::More.
The problem I see here that you have wildly different opinions of
what the standard equals should be. At the moment, all other things
being equal, Test::More's standard equals is string compare. I don't
think this is documented, but it's what it does. Since is_deeply is
part of the Test::More package, it should also IMO by default use
string compare.
> The reason I want it to fail is because if I pass these objects (and
> they are definitely objects, they're only strings if you squint) into
> some other function which calls a method on them then "bar" vs "baz"
> might be a very crucial difference. Or if I pass them to a function
> that behaves differently for strings and objects, I'll get the object
> behaviour, not the string behaviour.
Then you need to write a comparison function for your objects. One that
satisfies your definition of equal. You are trying to warp Test::More's
definition of what's equal. This is bad.
Anyway, there is no such thing as general equality, there is only equal
for this purpose. That's why perl has eq and ==. Perl's standard
equality tests aren't always sufficient and you sometimes have to write
a comparator that does exactly what you want.
As far as I can see that's what's happening here. There is a comparison
method and it just so happens that you don't like the kind of equality
it's testing. Other people do and have been using the standard method.
If you change it now you're probaly going to break a fair number of test
suites. I think it's a really bad idea to change what a method does when
people are using it and relying on the current behaviour.
> For me, it comes down to 2 things, utility and the total pain in the backside
> that it would be to even get close to implementing what's being asked for.
>
> <utility>
> Which is more useful?
Which one is more useful depends on what you want/expect to happen.
is_deeply is documented to be like is, but recurses over structures. If
it's supposed to be like is, then it should be doing eq comparisons. It
should not be hoking about in the internals of objects.
The behaviour that you want is no doubt useful, it's just not what
is_deeply is supposed to be doing (as documented).
andrew
--
Virgo: (Aug. 23 - Sept. 22)
It's time to start paying more attention to the things that make life
worthwhile, such as oxygen molecules.
