> Smart Matching in Perl 5.10 > http://www.szabgab.com/blog/2007/12/1198487688.html
I actually think this new feature is representative of one of Perl's design flaws. Larry Wall sees Perl as based on a number of design principles, most of which I agree are good guidelines for programming language design. But some of them tend to conflict with each other: 1. "Different things should look different. Similar things should look similar." -> http://www.perl.org.il/presentations/larry-wall-present-continuous-future-perfect/transcript.html 2. "Do What I Mean" or "Do the Right Thing." The problem is that doing "the right thing" requires the compiler to do *different* things with the same (or very similar) code, depending on its understanding of the "right" thing. In this case, we have a single operator ~~ which can either mean: - Do these numbers have the same value? - Do these strings have the same characters? - Do this number and this string represent more or less the same thing? - Does this string match this regular expression? - Is this element found in this array? - Is this element one of the keys of this hash? - Do these arrays have the same elements? - Do these hashes have the same keys? - etc., etc., etc. Keeping track of all these cases and how they interact is not necessarily intuitive, and will likely call for frequent reference to the documentation. That's because they're fundamentally doing *different* things, even though they all look the same. And when you say it checks if two arrays have the "same" elements, does it check whether they are identical? Or whether they succeed when smart-matched themselves? Finally, note that with eq for strings, == for numbers and ~~ for smart matching, Perl still lacks any single operator which can tell you if two scalars (let alone two arrays or hashes) are simply identical - contain the same exact string and/or number and/or undef and/or reference. (That may be an impossible mission because of automagical string/number conversion in scalars - another example of DWIM conflicting with different things looking different.) Unfortunately, the "I" in "DWIM" refers not to the programmer but to the compiler. I'd rather the compiler always do something well-defined, obvious and consistent, rather than applying complex heuristics which ultimately make "simple" code do hard-to-guess things. The more I use Perl, the more I conclude that DWIM is a language design anti-pattern. It's a shame, since on most of his design principles, Larry is right on the mark. Regards, Jason Elbaum _______________________________________________ Perl mailing list [email protected] http://perl.org.il/mailman/listinfo/perl
