develooper Front page | perl.perl5.porters | Postings from February 2011

Re: [PATCH] use feature 'method' take two

Thread Previous | Thread Next
From:
Sam Vilain
Date:
February 2, 2011 17:54
Subject:
Re: [PATCH] use feature 'method' take two
Message ID:
4D4A0AE8.9090304@vilain.net
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.

Sam

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About