Skip Menu |

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

Report information
The Basics
Id: 39901
Status: resolved
Priority: 0/
Queue: Method-Signatures

People
Owner: Nobody in particular
Requestors: SREZIC [...] cpan.org
Cc: randomcoder1 [...] gmail.com
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: signature ($a, @b, $c)
(This report is for version 20080108) When using a ($a,@b,$c) signature, the behavior is somewhat surprising. Here the test script: #!/usr/bin/perl -w package Bla; use Method::Signatures; warn $Method::Signatures::VERSION; method new ($class:) { bless {}, $class; } method hello ($a, @b, $c) { warn $a; warn join(",",@b); warn $c; } Bla->new->hello(1, 2, 3); __END__ Output is: 20081008 at /tmp/ms.pl line 18. 1 at /tmp/ms.pl line 25. 2,3 at /tmp/ms.pl line 26. 3 at /tmp/ms.pl line 27. When using Deparse, I see that the parameter handling is resolved like this: my $a = $_[0]; my(@b) = @_[1 .. $#_]; my $c = $_[2]; Maybe it would be better to use my(@b) = @_[1 .. $#_-1]; instead here? Or just forbid any arguments after a @array argument? Regards, Slaven
Subject: Re: [rt.cpan.org #39901] signature ($a, @b, $c)
Date: Wed, 08 Oct 2008 19:15:31 -0400
To: bug-Method-Signatures [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Slaven_Rezic via RT wrote: Show quoted text
> When using Deparse, I see that the parameter handling is resolved like this: > > my $a = $_[0]; > my(@b) = @_[1 .. $#_]; > my $c = $_[2]; > > Maybe it would be better to use my(@b) = @_[1 .. $#_-1]; instead here? > Or just forbid any arguments after a @array argument?
There's almost no error handling on arguments right now. Just required and named parameters. There's plenty of fun things you can get it to do. A prototype of ($a, @b, $c) is possible, just so long as everything to the right of the array is required. I think there's enough information in the current signature logic to figure that out. However it does have an air of desperation about it. As if the rule is "make it fit however you can". Wedging an array in the middle of an argument list is less necessary with named parameters and aliasing. ($a, \@b, $c) makes more sense as does ($a, $c, :\@b). Other edge cases. Given... ($a?, @b) what does passing in (42) mean? If we "feed to the left first" then it's $a = 42, @b = ()? which is an error because @b is required. If we prefer required arguments ("make it fit") then it's $a = undef, @b = (42) but then what's (23, 42); Is that $a = 23, @b = 42? or @b = (23, 42) Then what's ($a?, @b?) do? Simplest thing to do is forbid it for now, maybe open it up later if there is a Great Need. -- 87. If the thought of something makes me giggle for longer than 15 seconds, I am to assume that I am not allowed to do it. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
On Wed Oct 08 19:16:30 2008, schwern@pobox.com wrote: Show quoted text
> Slaven_Rezic via RT wrote:
> > When using Deparse, I see that the parameter handling is resolved
> like this:
> > > > my $a = $_[0]; > > my(@b) = @_[1 .. $#_]; > > my $c = $_[2]; > > > > Maybe it would be better to use my(@b) = @_[1 .. $#_-1]; instead
> here?
> > Or just forbid any arguments after a @array argument?
> > There's almost no error handling on arguments right now. Just > required and > named parameters. There's plenty of fun things you can get it to do. > > A prototype of ($a, @b, $c) is possible, just so long as everything to > the > right of the array is required. I think there's enough information in > the > current signature logic to figure that out. However it does have an > air of > desperation about it. As if the rule is "make it fit however you > can". > Wedging an array in the middle of an argument list is less necessary > with > named parameters and aliasing. ($a, \@b, $c) makes more sense as does > ($a, > $c, :\@b). > > Other edge cases. Given... > > ($a?, @b) > > what does passing in (42) mean? > > If we "feed to the left first" then it's $a = 42, @b = ()? which is an > error > because @b is required. > > If we prefer required arguments ("make it fit") then it's $a = undef, > @b = > (42) but then what's (23, 42); Is that $a = 23, @b = 42? or @b = (23, > 42) > > Then what's ($a?, @b?) do? > > Simplest thing to do is forbid it for now, maybe open it up later if > there is > a Great Need. > >
I made a test file with some test cases regarding array params here: git://bbbike.dyndns.org/method-signatures Note that the machine is not permanently up, but most of the time. Regards, Slaven
Subject: Re: [rt.cpan.org #39901] signature ($a, @b, $c)
Date: Sun, 19 Oct 2008 14:51:44 -0700
To: bug-Method-Signatures [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Slaven_Rezic via RT wrote: Show quoted text
> I made a test file with some test cases regarding array params here: > git://bbbike.dyndns.org/method-signatures > > Note that the machine is not permanently up, but most of the time.
Thanks. In the future, forking on github would be easier to work with (and it's up more than most of the time). Meanwhile, I'm not much of a git guru. How do I merge this? -- Stabbing you in the face so you don't have to.
Subject: Re: [rt.cpan.org #39901] signature ($a, @b, $c)
Date: 20 Oct 2008 23:39:02 +0200
To: bug-Method-Signatures [...] rt.cpan.org
From: Slaven Rezic <slaven [...] rezic.de>
"Michael G Schwern via RT" <bug-Method-Signatures@rt.cpan.org> writes: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=39901 > > > Slaven_Rezic via RT wrote:
> > I made a test file with some test cases regarding array params here: > > git://bbbike.dyndns.org/method-signatures > > > > Note that the machine is not permanently up, but most of the time.
> > Thanks. In the future, forking on github would be easier to work with (and > it's up more than most of the time). > > Meanwhile, I'm not much of a git guru. How do I merge this? >
Me neither. Probably something like git-pull git://bbbike.dyndns.org/method-signatures master could work. -- Slaven Rezic - slaven <at> rezic <dot> de tksm - Perl/Tk program for searching and replacing in multiple files http://ptktools.sourceforge.net/#tksm
Subject: Re: [rt.cpan.org #39901] signature ($a, @b, $c)
Date: Mon, 20 Oct 2008 17:23:57 -0700
To: bug-Method-Signatures [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
slaven@rezic.de via RT wrote: Show quoted text
> Me neither. Probably something like > > git-pull git://bbbike.dyndns.org/method-signatures master > > could work.
That worked, thanks! -- Stabbing you in the face for your own good.
Pardon me but I am interested in this module , so I would have some comments and some questions. On Wed Oct 08 19:16:30 2008, schwern@pobox.com wrote: Show quoted text
> Slaven_Rezic via RT wrote:
> > When using Deparse, I see that the parameter handling is resolved
> like this:
> > > > my $a = $_[0]; > > my(@b) = @_[1 .. $#_]; > > my $c = $_[2]; > > > > Maybe it would be better to use my(@b) = @_[1 .. $#_-1]; instead
> here?
> > Or just forbid any arguments after a @array argument?
> > There's almost no error handling on arguments right now. Just > required and > named parameters. There's plenty of fun things you can get it to do. > > A prototype of ($a, @b, $c) is possible, just so long as everything to > the > right of the array is required. I think there's enough information in > the > current signature logic to figure that out.
This particular case should be easy to figure out. However there could be ambigous cases such as: ($a,@b,$c,@d). The problem with this is that you don't know how big b is and how big @d is. But there is also a case in which this shouldn't be ambigous. When you pass it 4 parameters it's pretty clear that one goes into $a , one into @b , one in $c and one in @d. If you pass it 5 however it starts getting weird. The same story can be said for ($a,@b,@d,$c). Can subs have signatures with hashes as parameters ? (didn't see much of that in the docs) Show quoted text
> However it does have an air of > desperation about it. As if the rule is "make it fit however you > can". > Wedging an array in the middle of an argument list is less necessary > with > named parameters and aliasing. ($a, \@b, $c) makes more sense as does > ($a, > $c, :\@b). >
Could the module also support parameter de-construction ? Like we have in Javascript ( recently ) and Prolog ( but here we will have just one unification because we cannot afford to be ambigous , not in Perl that is). www.cefns.nau.edu/~jg455/classes/s09/cs396/pdf/10_prolog.pdf Or for javascript it's called "Destructuring assignment" https://developer.mozilla.org/en/ New_in_JavaScript_1.7#Destructuring_assignment Could we have these as well ? If we did , you could write ($a,[@b],$c) and it @b would have the needed value. Is this implemented already or does it work the same with ($a,\@b,$c) -- Your bugs , they are afraid of me.
I'm not seeing an actual issue here, and this ticket is several years old. I'm going to resolve it, but, if anyone involved wants to clarify what should be fixed/changed, please feel free to reopen it.
On Thu Nov 01 20:46:10 2012, BAREFOOT wrote: Show quoted text
> I'm not seeing an actual issue here, and this ticket is several years > old. I'm going to resolve it, but, if anyone involved wants to clarify > what should be fixed/changed, please feel free to reopen it.
The original issue with the signature ($a, @b, $c) doing odd things has long since been resolved. Slurpy positional parameters can only come at the end, so ($a, @b, $c) is now a compile time error. There was discussion of MS turning ($a, @b, $c) into something like... my $a = shift; my $c = pop; my @b = @_; ...but didn't get anywhere. There's lots of edge cases and need wasn't demonstrated. The possibility is still open, but should be dealt with in a separate issue.