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

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

Thread Previous | Thread Next
Ricardo Signes
July 26, 2014 23:16
Re: New feature proposal : <<>> to disable magic open of ARGV
Message ID:
I'm quoting Rafael slightly out of order!

* Rafael Garcia-Suarez <> [2014-07-24T16:06:11]
> It's more syntactic sugar than new operator. That said, there are benefits
> and drawback in the 2 approaches.

I think you did a good job hitting the nail on the head with the same things
I'd thought about this.  (Plus eof(), which I had not considered!)

> So what would be a pragma name ? secure::open ? open::nomagic ?

I'm not too worried about the name yet.  Of those two, I prefer 'open::nomagic'
because "no magic" is a bit safer of a claim than "secure." :)  And we'll want
to be clear whether this is affecting "open" or "open when dealing with ARGV".
Let's come back to it, though?  I'm more concerned about whether syntax or a
pragma will pay off better in the long run.

> Con: The syntax is backward-compatible, so technically we don't *need* a new
> pragma to enable it. <<>> optimises for less verbosity.
> Pro: However on one-liners without a pragma we lack a way to transform the
> implicit while(<>) of -n or -p into a while(<<>>).

I think Abigail was right to note that we have to be wary of spooky action at a
distance.  On the other hand, I think that what you've given us is much more
useful as a fixed default than an optional new behavior.  That is: in *most*
circumstances, I think the behavior of <> given @ARGV of ("rm -rfv *|") is
going to surprise.  Sure, it's documented, but that's not always a good reason
to expect people to have the right expectations. :)
(Also documented: ARGV::readonly -- but does anybody use it?)

So, anyway, there are three reasons to want syntax for this:

* there's no question about what "kind" of <> is active
* no pragma/feature is needed to make it available
* you can use both in one program (although I think this is a stretch! 😄 )

...and some reasons to avoid it:

* the programmer needs to remember to use the new form to avoid magic
* it doesn't help with -n etc.

Abigail notes that command-line-switch-generated code is often a place where we
*do* want the magic.  So do we want a way to get -n-but-with-nomagic-open?  Ed
and Rafael both seemed to like -P-and-so-on.

To me, the most significant concern is probably the one about improving our
defaults.  I'm not sure I think this is the best solution, but let me know if
you think it's clearly better or worse, or if it suggests anything else to you:

* 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
* ...and it's on in the while() code generated by -n
* ...but we have -N and -P

Although in my fantasy world, I'd make -n and -p *not* use magic open argv, I
think we're liable to break too many familiar one-liners.  I also think we'll
better off making sure that the behavior of -p/-P is always *explicit*, rather
than tied to -E/-e.

Like I said: do you think this is better, worse, or just different?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About