All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Is the alpha flag a matter of concept (unsound/fragile) or a matter of effort (just not done yet)?

It might be fragile. So far it's holding up well, but I haven't done anything major with it and I'm wary of building this on top of so much scary tech. Devel::Declare has a few bugs (it causes the debugger to spin like a top) that I hope mst will clear up shortly.

Second is the prototyping syntax and behaviors. Since I'm creating, essentially, a new language feature here I'd like it to get knocked around some before locking it in place. I'm pretty happy with how it's come out, and if I stabilized with ju

While they are definitely a possibility, and you're not the firstperson to ask for them, I'm wary of trying to mirror Perl 6's named parameters [perlcabal.org] right now for a number of reasons. First, they're notnecessary just now. Method::Signatures has a nice bag of problems todeal with already and the signature syntax is extensible. And Ihaven't given them a lot of thought.

Second, Perl 6 has all sorts of magic at the caller's end to forcenamed vs positional parameters. We have none of that. All we can dois, as you suggest, treat a hash ref as positional. But that leavessome ambiguity...

method foo( $things ) {...}

Class->foo({ things => 42 });

What's in $things? Currently it's { things => 42 }. Under namedparameters it might be just 42. Or maybe not. It's ambiguous.

Because named parameters are implied in every method, it means every method has to have a little extra code to check if the first argument is a hash ref. This adds a performance hit of about 10-15% to an empty method call whether or not you use it.