This queue is for tickets about the Method-Signatures CPAN distribution.

Report information
The Basics
Id:
93336
Status:
open
Priority:
Low/Low

People
Owner:
Nobody in particular
Requestors:
perl [...] toby.ink
Cc:
AdminCc:

BugTracker
Severity:
Wishlist
Broken in:
(no value)
Fixed in:
(no value)



Subject: Wishlist for Perl 5.20 signature compatibility: allow sub attributes to precede the signature
Method::Signatures, along with most other similar modules on CPAN, has used the following syntax to define a sub with both a signature and an attribute: method foo ($bar) :Baz { ... } Meanwhile Perl 5.20 seems to be taking the more questionable approach of: sub foo :Baz ($self, $bar) { ... } It ought to be fairly simple for Method::Signatures to allow attributes to be provided in *both* locations (i.e. both before and after the signature). Note that when attributes are provided *before* the signature, the whitespace separating them from the signature is significant. Consider the following two declarations: sub foo :Baz ($self, $bar) { ... } sub foo :Baz($self, $bar) { ... } The former declaration has an attribute of ":Baz" followed by a signature. The latter has an attribute of ":Baz($self, $bar)" but no signature. The significance of whitespace here has been confirmed to be intentional by Zefram and others on #p5p.
Show quoted text
> : > : > Meanwhile Perl 5.20 seems to be taking the more questionable approach > of: > > sub foo :Baz ($self, $bar) { ... } > : > :
This one I'm less thrilled with. :-/ By 5.20, are we talking about method signatures in core (which I believe Peter Martini was working on)? I probably should have tried to follow that effort more closely. <sigh> What does Perl 6 do in this case? does it even _have_ attributes for subs? Personally, I like to stick close to the P6 syntax where possible, for a few reasons.
On 2014-02-27T04:27:43Z, BAREFOOT wrote:
Show quoted text
> By 5.20, are we talking about method signatures in > core (which I believe Peter Martini was working > on)? I probably should have tried to follow that > effort more closely. <sigh>
Yes. Though the current core implementation is courtesy of Zefram.
Show quoted text
> What does Perl 6 do in this case? does it even > _have_ attributes for subs?
It does not. The closest it has is traits, which are mentioned as not yet implemented in the Method::Signatures documentation - see https://metacpan.org/pod/Method::Signatures#What-about I'm also not especially keen on attributes appearing before the signature, especially because it becomes a rare case of whitespace becoming significant in Perl. The documentation for the syntax can be found here: http://search.cpan.org/~tonyc/perl-5.19.9/pod/perlsub.pod#Signatures The example given is: sub foo :prototype($$) ($left, $right) { return $left + $right; } It is my assumption that other attributes (e.g. :lvalue) are also expected to appear in this position.
Show quoted text
> The documentation for the syntax can be found here: > > http://search.cpan.org/~tonyc/perl-5.19.9/pod/perlsub.pod#Signatures
Yep, took a look through all that. It is what it is, I reckon. <shrug>
Show quoted text
> I'm also not especially keen on attributes appearing before the > signature, especially because it becomes a rare case of whitespace > becoming significant in Perl.
Well, my main concern is that, being that it's all experimental, it's at least _possible_ that they end up changing their minds about it and putting it at the end after all. And I certainly don't want to be chasing their design. But, OTOH, I don't really have any reason to believe that that's at all likely. I think the best course of action is to do as you suggest and allow the attributes in both positions. That way we maintain backcompat, forward-compat, and hedge our bets as where things eventually land. I've opened [GitHub #99](https://github.com/schwern/method-signatures/issues/99) to track this as well.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.