Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It's be keen to see two more things supported.

    First, it'd be nice to say, "Yes, I just want named arguments, but they're all in $_[1] as a hashref. The rest is empty."

      $obj->method({ named => 'arguments' });

    Secondly, "Yeah, I have positional and named arguments, with all the named arguments in a hashref at the end."

      $obj->method($arg1, $arg2, { named => 'args' });

    This would cover nearly all my code's methods.

    (Maybe I should STFU and WSFC.)

    --
    rjbs
    • To the hash ref, I don't deny it's common, but I ask why do we do that? One reason is to try and save a copy, if the hash happens to be huge. But they aren't, and if they are do you really want to enumerate all the names? And anyway, breaking the hash ref down into a bunch of scalars wastes all that memory savings anyway.

      Another reason is to leave open the possibility of passing in more arguments.

      $obj->method({ this => 'that' }, 42);

      in which case you're not really passing in named arguments else that new positional argument could just be a named one.

      $obj->method({ this => 'that', stuff => 42 });

      And you no longer need the hash ref, just make it a hash.

      Otherwise, what you're really passing in that hash ref is not named arguments but a lump of data. For example...

      method new ($class: \%data, $something_else) {
          my $self = bless {%data}, $class;
       
          $self->wibble($something_else);
      }

      To chop up %data into a bunch of scalars makes no sense.

      As for the hash-ref at end, unless you have optional positional params its no longer necessary.

      method foo ($this, $that, :$named) {
          ...
      }
       
      $obj->method($arg1, $arg2, named => 'args');

      Of course, I'm sure I'm missing something important and TMTOWTDI reigns. And there's no real reason it can't handle named arguments as hash refs. The real block is always deciding what the syntax should be. Since it's a good idea to make the signature look like how it's called...

      method foo( $this, $that, {:$foo, :$bar} );

      Which opens up the possibility of allowing the named hash-ref params coming first.

      method foo( {:$foo, :$bar}, $this, $that );

      Or even the special case "slurp the hash ref off the end, then resolve the possibly optional positionals".

      method foo( $this?, $that?, {:$foo, :$bar} );

      In order for any of this to work and remain unambiguous, the hash ref would be required by default.

      • Apart from anything else, the biggest argument is:

        If I don't have to change the calling semantics, I can actually use this in old code. If I have to update every caller to pass a list rather than a hashref, I am not going to do it. If I can't update my old codebase to use this, I am not likely to start using it for new code, either.

        --
        rjbs
      • One reason is to try and save a copy

        The only good reason is that it forces an “Odd number of elements” warning to be emitted from the calling site without having to add any code to the callee. Obviously this does not apply in your module’s case.