develooper Front page | perl.perl5.porters | Postings from December 2008

Re: Proposal: Named parameters for 5.12

Thread Previous | Thread Next
Matt S Trout
December 19, 2008 06:54
Re: Proposal: Named parameters for 5.12
Message ID:
On Thu, Dec 18, 2008 at 02:07:23PM +0000, Tim Bunce wrote:
> On Thu, Dec 18, 2008 at 10:55:38AM +0100, Johan Vromans wrote:
> > Florian Ragwitz <> writes:
> > 
> > >
> > 
> > Could this be enhanced to turn
> > 
> >    sub square ($num) : method { 
> > 
> > into
> > 
> >    sub square {
> >      my ($self, $num) = @_;
> >      
> > (Although I'd prefer "method square ($num){" )
> Either way, shouldn't we be aiming to match the syntax to the semantics
> in a way that's consistent with Perl 6? In other words require "is copy":
>      sub square ($num is copy) : method { 
> (or  method square ($num is copy) { )
> I think if we don't we'll be regretting it in a few years when perl5 and
> perl6 are coexisting and perl6 will be running perl5 code. People will
> be getting mighty confused.

Different languages are different.

I think possibly a 6mode might be a good idea later (see Perl6::Contexts
for a fascinating chunk of 6mode on the CPAN being ignored) but given
'sub' isn't doing that and never has done, I don't see why 'method' should.

Basically, I don't see why we should sacrifice perl5-ish-ness just because
the idea is sort-of from perl6 among other things and we want to try and
provide perl6-ish-ness.

I still believe that rgs' original proposal, where signatures default to
a pure, simple, perl5 standard usage @_ unroll, is the best default
(basically what and MooseX::Method::Signatures do).

In the meantime, MooseX::Method::Signatures continues to support steadily
more of the perl6 signature grammar in so far as it makes sense for perl5,
and patches to that to make it possible to be more 6-like would be interesting.

Then people can test out in the real world whether the additional 6ishness
is as surprising in perl5 as I think it will be.

We can prototype this on CPAN.

Therefore, we should prototype this on CPAN.

I am not in favour of coring anything that people haven't already extensively
tried off CPAN.

Let's quit the bikeshedding and write some code. If you want to keep
arguing the debate, please can we at least move it to perl5-syntax on so it doesn't get in the way of adding features
that are already cooked to perl5 please?

      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director          
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?  

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About