Front page | perl.perl5.porters |
Postings from July 2012
It seems reasonable to me to argue that "in" is too specific, or not powerful enough, to bother including in Perl, compared to more flexible constructs such as the any() provided by Perl6::Junction. I don't agree with that, because I think "is this an element of that list" is a basic concept that is very commonly needed, and which deserves to have an easy and utterly clear way to write it, and I think "$x in (list)" is a lot clearer than "$x eq any(list)". But it's certainly reasonable to think otherwise. But that has nothing to do with types. You wrote originally: > We're not going to be adding an `in` operator, because it goes against the > idea of where Perl decides what type to use. The simple version of "in" I have discussed does no such thing. It has exactly the same treatment of numeric and string type as all the existing comparative operators, each of which comes in numeric and string flavors. Yes, each of those flavors would need to be justified as useful to bother including it in Perl. But they are entirely consistent with Perl's treatment of types. On Fri, Jul 6, 2012 at 5:13 AM, Ricardo Signes <perl.p5p@rjbs.manxome.org>wrote: > The use of "eq" is the primary type issue. If we need a numeric in, then > now we're talking about *two* operators to justify, each with one very specific > use. On the other hand, you can use any() with all sorts of comparitors > and > values. > -- Aaron Priven, aaron@priven.comThread Previous | Thread Next