use Perl

• Sweet! But are attributes possible? (Score:1)

  by rhesa (5696)

  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.
  • Re: (Score:1)

    by Aristotle (5147)

    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.
    • Re: (Score:2)

      by Ovid (2709)

      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?
      • Re: (Score:1)

        by tsee (4409)

        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.
        • Re: (Score:1)

          by Alias (5735)

          Indeed.

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

            by Aristotle (5147)

            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.
  • Re: (Score:2)

    by schwern (1528)

    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.
• Launch from Moonbase Alpha (Score:1)

  by jplindstrom (594)

  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?
  • Re: (Score:2)

    by schwern (1528)

    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
    • Re: (Score:1)

      by jplindstrom (594)

      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*
      • Re: (Score:2)

        by schwern (1528)

        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