logo
Free, unlimited AI code reviews that run on commit
git-lrc git-lrc GitHub Install Now We'd appreciate a star git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt

Kwargs - Simple, clean handing of named/keyword arguments.

Author

       Paul Driver <frodwith@cpan.org>

Exports

       Two functions (kw and kwn) are exported by default. You can also ask for them individually or rename them
       to something else.  See Sub::Exporter for details.

   kw(@array,@names)
       Short for "kwn(@array, 0, @names)"

   kwn(@array,$number_of_positional_args,@names)
       Conceptually shifts off n positional arguments from array, then figures out whether the rest of the array
       is a list of key-value pairs or a single argument (usually, but not necessarily, a hashref). If you
       passed in any @names, these are used as keys into the hash, and the values at those keys are appended to
       any positional arguments and returned.  If you do not pass @names, you will get a hashref (or whatever
       the single argument was, like a tied object) back.

       Note that if the single argument cannot be dereferenced as a hashref, this can die. No attempt is made by
       this module to handle the exception.

Name

       Kwargs - Simple, clean handing of named/keyword arguments.

Synopsis

           use Kwargs;

           # just named
           my ($foo, $bar, baz) = kw @_, qw(foo bar baz);

           # positional followed by named
           my ($pos, $opt_one, $opt_two) = kwn @_, 1, qw(opt_one opt_two)

           # just a hashref
           my $opts = kw @_;

           # positional then hashref
           my ($one, $two, $opts) = kwn @_, 2;

Version

       version 0.01

Why?

       Named arguments are good, especially when you take lots of (sometimes optional) arguments. There are two
       styles of passing named arguments (by convention) in perl though, with and without braces:

           sub foo {
               my $args = shift;
               my $bar  = $args->{bar};
           }

           foo({ bar => 'baz' });

           sub bar {
               my %args = @_;
               my $foo  = $args{foo};
           }

           bar(foo => 'baz');

       If you want to support both calling styles (because it should be mainly a style issue), then you have to
       do something like this:

           sub foo {
               my $args = ref $_[0] eq 'HASH' ? $_[0] : { @_ };
               my $bar  = $args->{bar};
           }

       Which is annoying, and not even entirely correct. What if someone wanted to pass in a tied object for
       their optional arguments? That could work, but what are the right semantics for checking for it?  It also
       gets uglier if you want to unpack your keyword arguments in one line for clarity:

           sub foo {
               my ($one, $two, $three) =
                   @{ ref $_[0] eq 'HASH' ? $_[0] : { @_ } }{qw(one two three) };
           }

       Did I say clarity? HAHAHAHAHA! Surely no one would actually put something like that in his code. Except I
       found myself typing this very thing, and ThatIsWhy.

See Also