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

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

Thread Previous | Thread Next
Rafael Garcia-Suarez
July 27, 2014 07:19
Re: New feature proposal : <<>> to disable magic open of ARGV
Message ID:
On 27 July 2014 01:16, Ricardo Signes <> wrote:
> 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

Why the double negation? use feature 'nomagic_open_argv' should
work similarly.

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