Front page | perl.perl5.porters |
Postings from February 2011
On 03/02/11 11:10, Zefram wrote: > chromatic wrote: >> but this swatch of optree building seems to do the trick. > Reasonably sane implementation. Though I strongly suspect you could > replace quite a bit of your added code with more reuse of existing code. > > I remain opposed to actually adding this to core. I don't see a > justification for favouring this particular set of semantics for the > "method" keyword over any of the other proposals; there's certainly > no consensus yet about which version of it from CPAN is preferred. > And of course it doesn't need to be in core to work. MooseX::Method::Signatures suffers from huge performance problems, precisely because it is *not* in core - it has to use PPI to parse the signatures. That sucks very very much. It also has to try and apply those signatures using very hairy code. There is absolutely zero way that these type constraints can be proved at compile time even when you declare variables' types so you pay a huge runtime penalty. A project I worked on had to back out some very elegant (IMHO) use of MXMS because it was simply too slow and had a huge number of dependencies. Adding type constraints is supposed to help the computer execute the code faster, not slower. This needs to be on Perl's long-term roadmap IMHO. I think that we already have a great "preferred" approach for method signatures. All of the modules on CPAN that I have looked at simply choose a subset of MXMS as a compromise position to be faster. If declared well enough in advance, "use 5.014" implies "use feature 'method'" is fair game IMHO. So long as there is a new API to access the parsed signature (yay, finally) and/or influence parsing (yuck) then the modules can adapt appropriately for the way forward. SamThread Previous | Thread Next