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. > 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. > 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)? > 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. 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. > > > 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? It transpires that people have different expectations about what a deep comparison entails; 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! > > > 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. > And the existing logic is not consistant. I reckon they're both consistent, just different. 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) ... Smylers
