Skip Menu |
 

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

Report information
The Basics
Id: 93336
Status: open
Priority: 0/
Queue: Method-Signatures

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

Bug Information
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
Download (untitled) / with headers
text/plain 949b
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.
Download (untitled) / with headers
text/plain 512b
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.
Download (untitled) / with headers
text/plain 990b
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 is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

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