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

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Sunday September 21, 2008
05:24 PM

Method::Signatures 0.05: speedy \@foo, closures work

[ #37506 ]

Using Matthijs van Duin's amazing Data::Alias module, the \@foo prototype now runs without a performance hit and @foo is a true lexical so closures work!

Method::Signatures 0.05 just released.

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.
  • I really like this. I was already tinkering with my extract_method script to make use of this gem of yours, and references were one of my unsolved issues. Thanks for fixing that so quickly :)

    Is there any chance code attributes will be supported? I'd like to use this with CGI::Application, and I bet it'd be cool for Catalyst too.

    • Catalyst has plans to obsolete the attribute syntax in favour of something very much like Method::Signatures, where you write something very roughly like

      action foo (/bar/baz) { ... }

      rather than

      sub foo : Chained('/bar/baz') { ... }

      … at least that was the idea when I last heard of it.

      • I'm already having issues with how "magical" bits of Catalyst are. Using hooks into the op-tree to stack the magic stuff on doesn't really reassure me. Does it seem warranted?

        • Assuming that these bits of Catalyst would also be done with Devel::Declare, and guessing that it's still mostly mst hacking on Devel::Declare, it all depends on whether he's hit by a bus, doesn't it?

          Personally, I'd rather worry about whether, by getting too cosy with the internals, Catalyst may eventually get similar breakage as Rails did between Ruby releases.

          • Indeed.

            Data::Alias has already horribly died once, plus it doesn't work anywhere that forbids the hack it uses to reference unexported symbols.

            • There was discussion on p5p a while back to pull modules like PadWalker and Data::Alias into the core on the basis that they are highly dependent on the internals, and need to be maintained in synch, but that never happened. I still think it’s a good idea; Data::Alias and PadWalker allow things that are indispensable in some situations, and leaving them fend for themselves seems like a choice that diminishes the value of the entire Perl ecosystem to an extent.

    • Is there any chance code attributes will be supported?

      I hadn't even thought about them. It could, I think it just involves more Devel::Declare black magic from mst to make it aware of attributes.

  • Very. Very. Cool.

    So it's alpha, with large blinking warning signs to stay away, etc. Is the alpha flag a matter of concept (unsound/fragile) or a matter of effort (just not done yet)?

    What's needed (if possible) to get it to a state so that people can use it?

    • 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

      • On the matter of syntax, do you have any ideas on named arguments (i.e. hash/hash ref automatically unpacked into the variables)?

        It seems doable to me. If the signature is misc vars, but you pass in a single hash ref, then... *magic*

        • While they are definitely a possibility, and you're not the first
          person 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 not
          necessary just now. Method::Signatures has a nice bag of problems to
          deal with already and the signature syntax is extensible. And I
          haven't given them a lot of thought.

          Second, Perl 6 has all sorts of magic at the caller's end to force
          named vs positional parameters. We have none of that. All we can do
          is, as you