Ed Avis <eda@waniasset.com> wrote: > David Mertens asked: >>Why would "$a in %hash" be equivalent to "exists $hash{$a}"? > > This is how it works in Python, and it seems natural in Perl too. It doesn't seem particularly natural to me: I find it bletcherous that, in Python, you can't statically tell the difference between an O(1) dict-existence test and an O(N) sequence-containment test (let alone a sequence-subsumption test). Given that we already have a perfectly cromulent operator for testing hash existence, and that the existing builtins that DWIM between array refs and hash refs aren't widely liked, I'm inclined to think that, if we acquire such an `in` operator, it shouldn't allow a hash on its RHS. Beyond that, I'm not at all convinced that this `in` is powerful enough to justify its own existence (regardless of whether it replicates the behaviour of `exists` on a hash). If it can only do string comparison, there are a variety of common tasks where you have to write out a longhand equivalent anyway; if it guesses as to whether you meant string equality or numeric equality or regex match or what have you, then it repeats essentially all the problems of smartmatch as currently implemented. The more I consider this, the more strongly I think that a wordier API is the right thing — along the lines of Test::Deep (now maintained by our fearless pumpking) or Leon's Smart::Match. I offer the following anecdotal support for this position. I currently have a codebase which makes substantial use of List::MoreUtils::any and friends for higher-order list-wise tests. By my reckoning, only about one occurrence in ten could be refactored to use an `in` operator of the form you suggest; but every single occurrence can be refactored to use Smart::Match (and almost all of them are made much clearer by doing so). -- Aaron Crane ** http://aaroncrane.co.uk/Thread Previous | Thread Next