On 7/1/05, _brian_d_foy <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Demerphq
> <[EMAIL PROTECTED]> wrote:
>
> > On 7/1/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > > After talking with Ovid some in the kitchen I'm of the opinion that
> > > is_deeply() is currently doing the right thing and that these tests cannot
> > > go. Largely it comes down to the Principle of Least Surprise.
> >
> > I cant agree with this analysis. If you go down this route surprise abounds.
>
> > (From my earlier post)
> >
> > is_deeply($x,$y); #ok
> >
> > $x->[0]{a}=1;
> > $y->[0]{a}=1;
> >
> > is_deeply($x,$y); #Surprise!
> >
> > Thats a MUCH bigger surprise IMO. And a fatal one for anybody really
> > relying on is_deeply.
>
> I don't see why the result of that second test is surprising, and
> even if it is, that it matters that you were surprised. I don't
> a priori expect that the same operations on two data structures
> that have the same values will make them also end up with the same
> values.
The entire basis of computer science is based around the idea that if
you do the same operation to two items that are the same the end
result is the same. Without this there is no predictability. No
program could ever be expected to run the same way twice. No operation
could be replied on to do the same thing twice. I mean computers are
deterministic, you have to work _really_ hard to make them
nondeterministic.
So now somehow when it comes to reference structure you throw all of
this tradition away and say "i dont expect it"?
Two structures are structurally different if they cannot pass the
addition test. Thats a point blank statement of fact and not a matter
of opinion.
Whether is_deeply() checks for this type of equivelency may be a
different question, but certainly there should be no debate about the
underlying issues here.
> Right now is_deeply acts like the other things in Test::More. I
> think things would be more confusing if it did things differently.
> I don't want is_deeply to tell me if things will be the same in the
> future, but if they have the same values when I test them.
We arent talking about "in the future". We are talking about now.
If they cant survive the addition test they are not the same now. This
makes no promises about the future. Maybe in the future they will be
able to pass the addition test. But if they cant do it now they are
different.
> In your example they start off looking the same, then change. is_deeply
> catches that.
"looking the same". Thats like comparing "\t" and " " x 8 on a device
with normal tab expansion. They look the same, but I suspect youd be
pissed off is is_deeply() thought they were the same. To me this is
what you are saying about structures.
>
> If you want to do it in a different way and think about the data
> structure in a way that Test::More doesn't, don't use is_deeply. :)
Actually in this case im arguing for the good of the community. I dont
need is_deeply() because I have Data::Dump::Streamer. A simple
is(scalar Dump($x)->Out,scalar Dump($y)->Out)
suffices to solve this problem quite well. My intention was to raise
the bar here, because in my eyes the bar is set very low indeed, and
the naming and documentation of is_deeply() falsly gives the
impression that it will do the same thing. You may expect some kind of
weird "refs only count when they arent empty and have different
content" but that isnt what its documented to provide. It says:
<quote>
Similar to is(), except that if $this and $that are hash or array
references, it does a deep comparison walking each data structure to
see if they are equivalent. If the two structures are different, it
will display the place where they start differing.
Test::Differences and Test::Deep provide more in-depth functionality
along these lines
</quote>
It specifically says "If the two structures are different, it will
display the place where they start differing." which is a lie. I
proposed to change the code to match the documentation. It looks like
a lot of folks here would prefer to change the documentation. I dont
think thats in the best interest of Perl. Others may disagree.
Ultimately its Schwern decision, but regardless the status quo is not
right.
cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
