I think you mean "This can't be very fun, but they keep doing it".
]]>Perl's smartmatch operator *is* its "in" operator (given a scalar-array comparison). To want for a Pythonic "in" is to want for Python's type system in place of Perl's:
>>> 1 in [1]
True
>>> 1 in ["1"]
False
>>> 1 in [True]
True
>>> "1" in [True]
False
Which may be nicer depending on your temperament, and can be achieved in Perl by using smart match in conjunction with wrapper classes to delineate between scalar subtypes.
]]>
if keys %hash in @array
meaning if any key in in the hash matches an element of the array..., I currently find that hard to express, or at least hard to remember how to express.
]]>Anyway, as a Perl user, I have only used Scalar ~~ Array(ref), a.k.a. for "in". Never used given/when, and does not plan to.
]]>Having a decentralized conversation across a multitude of blogs, tweets, etc. doesn't help convey those wishes and desires to the people that have the tuits to do this work.This is probably true, so perhaps this blog post can be a call to action: "If you want to weigh in on this, head on over to p5p..."
Keeping the conversation in one centralized location (p5p) is fine - but plaster every wall in every venue with signs pointing back to the conversation when it's a big one, about which the larger community might have valuable input.
]]>As regards p5p or not p5p: I really wouldn't wish it upon anybody to have to read any more of p5p than he or she really wants to. There's a lot of it, much of it boring or obscure. Shouting loud in a public place, "Hey, they're talking about something you probably care about!" when there's something clearly important going on is a really good idea.
I do hope that anybody who wants to bring their argument to the table to support or argue against the changes does come post on p5p, where these kinds of discussions can be had in one place. It's not really practical to have the actual debate of the issues spread across "the blogs." I try to keep up with what's getting posted on the ones I know about, but it's hard. I do read every message to p5p, though. :)
(p5p certainly is "in public." It's published in many places and anybody can join and post.)
]]>For some more on the difficulties with implementing ~~ behavior with pragmata, see this thread from p5p, in which Jesse L. began work on it and then ran into the problem described:
]]>package Answers; use smartmatch 'core'; use Sub::Exporter -setup => { exports => [qw( is_affirmative is_negative )], }; sub is_affirmative { lc( $_[0] ) ~~ qw( yes si oui ); } sub is_negative { lc( $_[0] ) ~~ qw( no non ); } 1;
The fact that is_affirmative
and is_negative
use smart match internally are just implementation details. Somebody who imports the functions into their namespace won't necessarily know that, so it would be pretty odd if their choice of smart match behaviour affected the workings of the is_affirmative
and is_negative
functions.
Yes, there are cases where you want to use your caller's choice of smart matching algorithm, such as the junctions example, where you might wish to define an any
function such that any(1, 2, 3)
will use numeric or string matching depending on the smart match algorithm in use by the caller. But that seems to me to be the exception rather than the rule. It could be handled by:
use smartmatch 'caller';]]>
Ricardo's proposal looked like a reasonable simplification to me.
For some perspective, I was only able to recently get our production system upgraded from Perl 5.8 to Perl 5.14. We haven't even started to use smart matching in our code yet. I imagine a lot of people are in the same boat. There's no better time to get it right than now.
With a positive outlook on growth, there will be more than double the users are smart match going forward than their all currently (due to those who haven't been able to upgrade plus new adoptions). Thus, it's better target that market, who doesn't care about backcompat.
I maintain some modules that suffer from too much backwards compatibility. Sometimes prioritizing the future instead of the past is a better choice.
]]>/I3az/
]]>