develooper Front page | perl.perl5.porters | Postings from September 2012

Re: Why smartmatch

Thread Previous | Thread Next
From:
Smylers
Date:
September 5, 2012 07:30
Subject:
Re: Why smartmatch
Message ID:
20120905143040.GZ1742@stripey.com
John Wiersba writes:

> As far as the number vs. string argument goes, I like perl's way of
> handling that for other functions that have similar issues, like sort,

Hi. Apologies for contributing to this thread so late; I hadn't been
following P5P, but have been alerted to this topic by Mark Allen's
splendid summary.

John's comparison with C<sort> appeals: it's another situation where
string or numeric comparison could be desired. In particular, one of
them is unambiguously the default, and t'other can be specified
explicitly; in no case does the behaviour depend on whether the scalar
is more like a number or a string, nor does it differ between variables
and literal constants.

That fits well with Perl having separate == and eq operators, and with
generally not needing to care about whether a value is a string or a
number.

It also made me wonder: how common are numeric comparisons required with
C<when>?

* For numeric codes, such as HTTP status codes, eq works fine.

* For classifying numeric values, such as converting raw scores into
  labels, an inequality operator such as <= will need to be used to
  check for each range in turn.

* For results of calculations a tolerance is often needed rather than
  precise equality. This could be achieved by Number::Tolerant, say,
  overloading ~~.

* For trivial integer arithmetic eq happens to work well enough in many
  situations too. It isn't ideal, and explicitly specifying numeric
  comparison is recommended, but sometimes it would do.

In what situations are numeric comparisons with C<when> required?

And, do such C<when> clauses typically come in a C<given> where all the
C<when>s use numeric comparisons (that is, the topic is being compared
against a bunch of different numbers), or in mixed-type C<when>s?

Kent Fredric writes:

> On 25 August 2012 06:18, David Golden <dagolden@cpan.org> wrote:
> 
> > According to the proposed precedence table, yes, because literals
> > are not ambiguous.  We can distinguish when(0) from when("0").
> >
> > ... there was agreement that for literals, we can DTRT.
> 
> My primary objection to this is it seems like something that could
> cause surprises for people, because I doubt people are going to
> *expect* literals to be treated differently to variables.

Indeed. That also really concerns me: a variable not being usable for
its value is a difference that many people would be surprised by. If
C<when (404)> works, it's disappointing that naming the magic number and
replacing that with C<when ($NOT_FOUND)> doesn't work.

This difference is also a different difference from other differences
people will likely have encountered elsewhere in Perl.

David Golden writes:

> I suspect that 90% of my use of given/when will be matching against
> literals or constants.

Looking at that from a different angle, I suspect 90+% of my use of
C<when> on simple scalars will be matching strings rather than numbers.

> I would gladly accept syntax to make my 90% case easy, simple and
> readable, even if it meant that I had to do something more complex in
> the rare case

Me too. String constants are the common case, falling under both your
and my 90%s. 

> ... where I wanted to test against something in a variable.

I'd say "where I wanted to test something numerically".

Not because I think testing variables is more common, or more important,
than testing numerically, but because it's less surprising -- and
therefore also easier to teach: variables can always be used for their
values; C<when>, C<sort>, C<eq> do string comparisons by default.

Cheers

Smylers
-- 
New series of TV puzzle show 'Only Connect' (some questions by me)
Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About