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.
  • Was that all pretty much just saying "we need an object system in core?"

    +1 for sentiment, but we need more than sentiment. We need a plan that p5p supports. (And, probably, a long-term feature branch in the core to prototype, test and get buy-in around.)

    As for the toolchain footnote, you're right, which is why I'm working on things like this [dagolden.com] and this [dagolden.com]. It can get better and it will get better.

    -- dagolden [dagolden.com]

    • Was that all pretty much just saying "we need an object system in core?"

      We need an object system and function/method signatures.

      We need a plan that p5p supports.

      I have no idea how to create this.

      • The function/method signature issue is very problematic because part of that deals with the philosophy of Perl. I, for example, sometimes find that static binding (compile time) of methods would make some problems magically go away, but I doubt that Perl 5 will ever be able to support that. Of course, signatures also might imply multimethods. That's another issue which would give people fits. Should all methods be multimethods or should we have to specify this directly?

        • Here's a secret, though: Perl 5.12 or 5.14 or whatever doesn't have to support all of those features to have useful function/method signatures. Even supporting only required positional parameters is useful for some 80% of extant code.

        • Considering all of this stuff already works in Perl 5 and is limited to a given lexical scope, I am having a really hard time seeing how this is 'impossible'.