On 7/1/05, Smylers <[EMAIL PROTECTED]> wrote: > demerphq writes: > > > Well that says there are two different behaviours that people expect. > > They are exclusive. > > Yes. We all want to do the least surprising thing, but it seems > different people are surprised by different things; whichever behaviour > is implemented some people are going to suffer unexpected results. > > If the number of people expecting each behaviour is similar then there > isn't much we can do about that. If it happens that one expectation is > held by a small number of people then it might make sense for them to be > the unlucky ones. > > I'm obviously only a single data point, and I don't claim my > expectations match anybody else's; I'm quite prepared to accept that I'm > in the set of "unlucky ones". > > > i think youve missed the point here. > > > > > > $a3=[$x,$x]; > > > > $a4=[$y,$z]; > > > > > > ... the data structures in each case are the same. > > > > No, the $x hash is present twice. Thus altering the $x hash and the $y > > hash equivelently results in what we all agree are different > > structures. Im saying that if that is possible then the originals > > structures were different in the first place. > > Ah, I see what you mean. Yes, I was missing the point -- thank you for > your patience and explaining it so well. > > Finally grasping that however hasn't changed my expectations.
So you mean you expected the first to pass and the second to fail? >From reading the code? > > The argument being made goes something like this: > > > > Because both arrays index 0 and 1 reference empty hashes they are > > equivelent. > > Reading the data from either of those data-structures, as they are at > the moment, they can be used interchangeably. But, as you've pointed > out, once you've written to them they may no longer be interchangeable. But how can they be "used interchangably" if they cant be interchanged after an identical store operation is performed on both? > > > If we were going to be consistant with our logic on this then we > > should say that > > > > [1,1] and [1,2] > > > > are the _same_ because both arrays index 0 and 1 contain numbers. Why > > do we care if they are they same numbers or not here, but we dont care > > when they are hashes? > > Clearly reading the data from those arrays yields different results; > they are interchangeable for neither reading nor writing. Surely you > can distinguish between structures which read the same as each other and > those that don't (even if you don't consider that a useful distinction > to make)? Well I dont see them as even reading the same as I consider the identity of the objects as critical attributes. In fact my expectations are pretty much in line with what DD does (or to a certain extent what it should do, as its a single pass dumper it has certain failings, hence the reason I wrote Data::Dump::Streamer which doesnt have any of these issues.) > > > Like I said. If I have two structures that are deep copies of each > > other I should be able to alter both in an equivelent way and still > > have them equivelent. > > That's the crux of the matter. It's plausible to consider structures > equivalent if they read the same; equally it's plausible to do so if > they behave the same when altered. Well obviously we are at an impasse. :-) I dont consider them to "read" the same at all, as any record of what objects were visited and how many times would end up quite different at the end of the process. > > Both are valid things to do, and consistent within themselves. And both > appear to be things that people consider deep comparisons. But > obviously each of them will not do in a situation where you wanted > t'other one. Well i dont consider is_deeply() to be consistant at all. I consider it to be inconsistant. > > > > is_deeply should be reliable and do what its name says. > > > > > > I think everybody's in agreement about that! There's just the > > > matter of agreeing what its name does say ... > > > > No. there is no agreement about it. > > You seriously think that anybody here is purposefully advocating a > position where the function should be unreliable or not do what it says? Actually yes. Thats my position in general. At least some people are advocating that is_deeply() be unreliable. And since is_deeply() would seem to strongly imply testing whether two objects are deep copies of each other it would seem it doesnt do what it says it does. The docs say: 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. To me there is only one interpretation of "deep comparison" and it isnt the one that is_deeply() currently uses. If is_deeply() isn't fixed (im starting to feel that this is the inevitable outcome of this debate, regardless of how wrong it is) then it should be reworded to something like: is_deeply() Similar to is(), except that if $this and $that are references, it does a paralell traversal of the reference structures comparing non references only. Should a discrepancy between non referential values occur is_deeply() will report where they start differing.. Contrary to its name it does NOT determine whether the two structures are isomorphic or true deep copies. For that you should use something else. > It transpires that people have different expectations about what a deep > comparison entails; I think that is because most people dont really understand what deep structural comparison means. Considering how often I see perl pro's get their understanding and descriptions of reference structures wrong I dont see that this is a big deal. It seems unusally common for even experienced perl programmers to make statements that betray serious misunderstandings of how perl manages variables and references. Not to pick on Schwern but his question about whether the original error I pointed out was really an error just underlines my point. > but I don't think anybody is considering the 2 > possible behaviours, thinking that the term "deep comparison" applies to > one of them and then suggesting that is_deeply should use the other one! Well, i suppose ill grant that. > > > > > The fact is it wouldnt be too difficult to support both [behaviours] > > > > off of the same code base. > > > > > > Then we're still in the position of arguing which should be the default > > > behaviour ... > > > > Yes. And I posit it should be the one that is most consistant. > > That was my point -- that even if we agree to have a flag, it doesn't > help the debate at all, cos all of the original arguments still apply. The flag would be internal to the routines that is_deeply() use not a flag to change is_deeply()'s behaviour. > > > And the existing logic is not consistant. > > I reckon they're both consistent, just different. Well, i guess im just thick or something. I cant see how the behaviour ive documented in this discussion can be described as consistent. > > Hmmm. I see we aren't even "consistent" on how to spell that particular > word! I can't be bothered to look it up to see which of us is right (or > whether both are valid) ... Your usage is constent with the spelling in the dictionary. :-) Cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
