Sure, any c getopt library accepts any command line source you give it, which may or may not be the one your program got. Likewise for Java.

Sure! Take for example the code in getopt(3) (I'm not posting it here in full because it's longish). Note how you have, essentially,

       #include <stdio.h>
       #include <getopt.h>

       int
       main (argc, argv)
            int argc;
            char **argv;
       {
           /* ... */
           getopt_long (argc, argv, "abc:d:012", /* short spec */
                        long_options, &option_index);
           /* ... */
       }
[download]

The "argc" and "argv" you're passing the library function getopt_long just happen to be the ones given to you on the command line. But if you'd have constructed any other, er, argument vector, you could have passed that instead.

The same thing happens in Java, when your entry point accepts a String args[], and passes that (or a different String[]) to the options parsing library.

Ah...I see what you're saying now. You want the ability to have the arguments parser act upon arbitrary arrays as opposed to always acting on @ARGV. If this gets implemented, I'd sure like to see @ARGV be the default. Because, just like in the examples that you site above, @ARGV will be what 99.99% of the people want. Of course, the devil's in that extra 0.001%. Something in the back of my mind tells me that Perl6 has multi-dispatch ala Java where you can have mutliple subroutines called the same thing, but the one that gets called is the one that has the right signature. If this is the case, you could do something like:

sub GetOpts()
{
   GetOpts(@ARGV);
}
sub GetOpts(@array) {
   #the real work is done here
}
[download]

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come