Front page | perl.perl5.porters |
Postings from July 2014
I'm quoting Rafael slightly out of order!
* Rafael Garcia-Suarez <rgs@consttype.org> [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?
--
rjbs
Thread Previous
|
Thread Next