develooper Front page | perl.perl5.porters | Postings from July 2014

Re: New feature proposal : <<>> to disable magic open of ARGV

Thread Previous | Thread Next
From:
Smylers
Date:
July 27, 2014 07:21
Subject:
Re: New feature proposal : <<>> to disable magic open of ARGV
Message ID:
20140727072122.GG2791@stripey.com
Ricardo Signes writes:

> To me, the most significant concern is probably the one about
> improving our defaults.

I think so too, though I'm mildly concerned about The Blub Paradox:
http://www.paulgraham.com/avg.html — I can't remember ever passing a
pipe as an argument to a Perl program, but perhaps that's because I've
been missing out on a useful feature. Or by using magic <> I've been
writing handy generic programs which other users can usefully pass pipes
to, and by removing the magic I'd also be removing a useful feature.

As such, it'd be good to hear from somebody who has used this feature
(whether successfully or disastrously).

> * use feature 'magic_open_argv'
> * ...which goes into the default feature bundle, and old versions
> * ...but not the new version's bundle, so it's off by default on use 5.22

That sounds good: safe by default, but anybody who knows they want the
magic can easily opt in. In particular, it means that the beginner
simply doesn't need to know about any of it.

> * ...and it's on in the while() code generated by -n

Even if the one-liner also supplies -Mv5.22? That could be confusing.

> * ...but we have -N and -P

I'm less persuaded of the need for these, because they require opting in
to safety and because of Abigail's point about a one-liner author being
in control of arguments. But they do make Perl more complicated — more
options in perlrun to have to learn.

And anybody giving examples of one-liners — whether in a Perl tutorial,
or a command for a sys-admin to run (and which just happens to be in
Perl) — has to continue to use the ‘unsafe’ -n and -p anyway for
backwards compatibility, or uses -N and -P and has readers being
frustrated with Perl because it doesn't work in their version, or has to
mention both with an explanation of which to use. None of those sound
like an improvement to me.

> I also think we'll better off making sure that the behavior of -p/-P
> is always *explicit*, rather than tied to -E/-e.

I think that introducing exceptions to what -E does would also be
unfortunate, in terms of adding to the cognitive load of learning Perl.

However, I note that -E is currently documented in two places, that
don't entirely agree.

Quick poll, before reading on past the following space: What do you
think -E does?
























Here are the two definitions:

• The feature docs say that -E enables the feature bundle for the
  version of Perl being used. So on perl 5.22, -E should be the same as
  use v5.22.

• perlrun says that -E enables all optional features. So on perl5.22 -E
  should enable magic_open_argv even though it isn't in the bundle for
  use v5.22.
  
Those two definitions are only resolve to the same features as long as
newer versions of Perl only add to the set of features in the default
feature bundle. Which is currently true. But this proposal is (sensibly,
it seems to me) is to remove a feature.

Whatever we decide about the behaviour of -n and -p, we should decide on
what the definition of -E actually is and fix the docs. I can see
benefits to either approach: both ‘make this behave the default way for
this version of Perl’, and ‘just give me all the features, without me
having to type out long -M lines to enable them’ could be useful.

I think the least-confusing approach would be to go with whatever most
users already think the definition for -E is.

Smylers
-- 
Girls don't wear their shoes out, and boys don't care about style?
  Clarks think so: http://j.mp/clarksgirlboyposters
Disagree? Don't want shops promoting gender stereotypes to children?
  Please sign the petition: http://j.mp/clarksgirlboypetition

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