You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reason will be displayed to describe this comment to others. Learn more.
I don't know if we need both. I didn't trace when/if/how process-cmd-args was called.
The reason I added it in process-cmd-args is because if it's not there, $*ARGFILES contains the original @*ARGS with all of the command line options and IO constructs such as lines try to open files named after those options.
The reason will be displayed to describe this comment to others. Learn more.
I've decided that IO::ArgFiles should be directly manipulating @*ARGS instead of having its own copy. That's how P5 does it :-).
Beyond that, I suspect that a MAIN subroutine that wants to have the unbound arguments captured into @*ARGS should capture and set it directly via
multi sub MAIN($arg1, $arg2, *@*ARGS) { ... }
and then $*ARGFILES should be smart enough to use that.
I'm handwaving a bit here, though, because if $_ARGFILES has already been consuming
some stuff before MAIN() was called, we may need some way to "reset" it if a new
@_ARGS has been created.
Or, $_ARGFILES could keep track of the identity of the current @_ARGS object and reset
itself if/when it detects a change. That sort of magic might be on the heavy side... but then
again $*ARGFILES Is already fairly magical to begin with.
The reason will be displayed to describe this comment to others. Learn more.
It seems like IO::ArgFiles is insufficiently lazy. It tries to capture @_ARGS at a particular point in time, but what it really should do is completely ignore @_ARGS until the last possible moment when it's needed (like when calling slurp() or get() or when someone tries to look at $*ARGFILES) So I tend to agree with your last paragraph.
6ec88fa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$*ARGFILES is already being set in terms.pm -- any reason for setting it here instead? Do we need both?
6ec88fa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if we need both. I didn't trace when/if/how
process-cmd-args
was called.The reason I added it in
process-cmd-args
is because if it's not there,$*ARGFILES
contains the original@*ARGS
with all of the command line options and IO constructs such aslines
try to open files named after those options.6ec88fa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've decided that IO::ArgFiles should be directly manipulating @*ARGS instead of having its own copy. That's how P5 does it :-).
Beyond that, I suspect that a MAIN subroutine that wants to have the unbound arguments captured into @*ARGS should capture and set it directly via
and then $*ARGFILES should be smart enough to use that.
I'm handwaving a bit here, though, because if $_ARGFILES has already been consuming
some stuff before MAIN() was called, we may need some way to "reset" it if a new
@_ARGS has been created.
Or, $_ARGFILES could keep track of the identity of the current @_ARGS object and reset
itself if/when it detects a change. That sort of magic might be on the heavy side... but then
again $*ARGFILES Is already fairly magical to begin with.
Pm
6ec88fa
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like IO::ArgFiles is insufficiently lazy. It tries to capture @_ARGS at a particular point in time, but what it really should do is completely ignore @_ARGS until the last possible moment when it's needed (like when calling slurp() or get() or when someone tries to look at $*ARGFILES) So I tend to agree with your last paragraph.