Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

Dov Wasserman wrote: My concern is that given an argument supplied as a pair (foo => "bar"), it is not clear which type of parameter is meant to be supplied. If there is no such named parameter, we know that the argument was intended for the slurpy hash. However, what if the method designer later a

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

"Aldo Calpini" <[EMAIL PROTECTED] > wrote in message ... > > if you decide to reimplement logError to be just: > sub logError {# implicit ([EMAIL PROTECTED]) > # ... > } > using a Pair, you still have someting (a Pair object) that you ca

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Wed, 2004-05-05 at 22:36, Dov Wasserman wrote: > sub logError($msg, Int +$prio = 4, *%errorInfo) { [...] > logError("Database error", module => "DB.pm", line => 263, prio => "HIGH"); > > After the New And Improved logError() routine is rolled out, it seems to me > that this log statement shoul

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > To distinguish these two cases, what if we used the := binding operator to > bind an argument to a named parameter: > > logError($err_msg, prio := 3); but how would this look like to a subroutine that is not defined to accept a named parameter c

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

"Aldo Calpini" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > > > > After the New And Improved logError() routine is rolled out, it seems to me > > that this log statement should generate a compile-time error, since the > > named In

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > After the New And Improved logError() routine is rolled out, it seems to me > that this log statement should generate a compile-time error, since the > named Int parameter "prio" is given a non-integer argument "HIGH". At best, > this should be a

Re: New Group proposed: subs (was Re: named parameters)

"Kyle R . Burton" <[EMAIL PROTECTED]> writes: > use self => 'self'; > use self => 'this'; Of course, if you _really_ want to avoid religious wars, you would need a non-selfish pragma name in the first place. -- Johan

Re: New Group proposed: subs (was Re: named parameters)

Glenn Linderman wrote: > Now what good meanings could we attribute to $myself and $I > ? Right. Remember, if it looks like Perl (and with the addition of $ME, it will), then it probably is Perl. :) J. David

Re: New Group proposed: subs (was Re: named parameters)

Andy Wardley wrote: > What about '$me'? It ties in nicely with 'my' (although perhaps for the > wrong reasons), it's half as much typing as 'self' or 'this' and we get > to annoy both sets of religious zealots at once. :-)= Yes! I love it!

Re: New Group proposed: subs (was Re: named parameters)

>Andy Wardley wrote: >> What about '$me'? It ties in nicely with 'my' (although perhaps for the >> wrong reasons), it's half as much typing as 'self' or 'this' and we get >> to annoy both sets of religious zealots at once. :-)= >Yes, absolutely. Now what good meanings could we attribute to $

Re: New Group proposed: subs (was Re: named parameters)

Andy Wardley wrote: > What about '$me'? It ties in nicely with 'my' (although perhaps for the > wrong reasons), it's half as much typing as 'self' or 'this' and we get > to annoy both sets of religious zealots at once. :-)= Yes, absolutely. Now what good meanings could we attribute to $mysel

Re: New Group proposed: subs (was Re: named parameters)

> > One of my many RFCs will include a proposal for a $SELF variable along > > those lines. > > Why not allow for the choice of the name of self, perhaps through a pragma? > > use self => 'self'; > use self => 'this'; > > or something along those lines -- since it's c

Re: New Group proposed: subs (was Re: named parameters)

At 10:43 AM 8/4/00 -0400, Kyle R . Burton wrote: > > One of my many RFCs will include a proposal for a $SELF variable along > > those lines. > >Why not allow for the choice of the name of self, perhaps through a pragma? > >use self => 'self'; >use self => 'this'; > >or something along those lines

Re: New Group proposed: subs (was Re: named parameters)

> One of my many RFCs will include a proposal for a $SELF variable along > those lines. Why not allow for the choice of the name of self, perhaps through a pragma? use self => 'self'; use self => 'this'; or something along those lines -- since it's currently up to the devleoper anyway. Somethi

Re: named parameters

At 04:37 AM 8/4/00 -0600, Tom Christiansen wrote: > >Point taken. But part of the goal was moving a lot of stuff out of CORE > >and making Perl faster. New features are great, but we should figure out > >whether or not they're truly CORE-worthy. Sticking it in a pragma like > >strict helps to solv

Re: New Group proposed: subs (was Re: named parameters)

>I hesitate to point out that the object who's method is called is the >actor, not what is acted upon. Therefore, we should be using the >nominative case, and go with $I :-) Actually, I'd argue dative (give $him "grief") or vocative ($brute->acting(qw/cassius strange/)). --tom

Re: named parameters

"Bryan C. Warnock" wrote: > It seems to me that whether something is CORE-worthy is really a > decision for the internals team. Whether something should be a valid, > meaningful construct in Perl, regardless of the implementation, is the > focus of the language team. The CORE of the Perl languag

Re: New Group proposed: subs (was Re: named parameters)

At 04:56 AM 8/4/00 -0600, Tom Christiansen wrote: > > > What about '$me'? It ties in nicely with 'my' (although perhaps > f > > > wrong reasons), it's half as much typing as 'self' or 'this' and we get > > > to annoy both sets of religious zealots at once. :-)= > > >You took the words ri

Re: New Group proposed: subs (was Re: named parameters)

On Fri, Aug 04, 2000 at 04:56:53AM -0600, Tom Christiansen wrote: > > > What about '$me'? It ties in nicely with 'my' (although perhaps f > > > wrong reasons), it's half as much typing as 'self' or 'this' and we get > > > to annoy both sets of religious zealots at once. :-)= > > >You too

Re: named parameters

Internals added to cc: On Fri, 04 Aug 2000, Nathan Wiger wrote: > Point taken. But part of the goal was moving a lot of stuff out of CORE > and making Perl faster. New features are great, but we should figure out > whether or not they're truly CORE-worthy. Sticking it in a pragma like > strict h

Re: named parameters

Ken Fox <[EMAIL PROTECTED]> writes: > Nathan Wiger wrote: > > Because it has opportunity for bloat, I would suggest it should be in a > > pragma: > > > >use strict 'prototypes'; > > Bloat? What bloat? I don't want to *bloat* all my programs by sticking > a zillion pragmas in just to turn on

Re: New Group proposed: subs (was Re: named parameters)

> > What about '$me'? It ties in nicely with 'my' (although perhaps f > > wrong reasons), it's half as much typing as 'self' or 'this' and we get > > to annoy both sets of religious zealots at once. :-)= >You took the words right out of my...err...fingers! >Although, of course, it will

Re: named parameters

>Point taken. But part of the goal was moving a lot of stuff out of CORE >and making Perl faster. New features are great, but we should figure out >whether or not they're truly CORE-worthy. Sticking it in a pragma like >strict helps to solve this issue, but as always TMTOWTDI. I find the notion t

Re: New Group proposed: subs (was Re: named parameters)

> What about '$me'? It ties in nicely with 'my' (although perhaps for the > wrong reasons), it's half as much typing as 'self' or 'this' and we get > to annoy both sets of religious zealots at once. :-)= You took the words right out of my...err...fingers! Although, of course, it wil

Re: New Group proposed: subs (was Re: named parameters)

> Before it's too late - please, don't impose either '$self' or '$this', > but make this a per-module choice. I deal with people of both these > religions... What about '$me'? It ties in nicely with 'my' (although perhaps for the wrong reasons), it's half as much typing as 'self' or 'this' an

Re: New Group proposed: subs (was Re: named parameters)

Damian Conway wrote: > > One of my many RFCs will include a proposal for a $SELF variable along > those lines. Before it's too late - please, don't impose either '$self' or '$this', but make this a per-module choice. I deal with people of both these religions... Hildo

Re: New Group proposed: subs (was Re: named parameters)

> I also hope that > >sub func : method { >my( $self, $foo, @bar ) = @_ ; >blah ; >} > > will become: > >sub func : method ( $foo, @bar ) { >blah ; >} > > (with $self automatically supplied) One of m

Re: New Group proposed: subs (was Re: named parameters)

Uri Guttman <[EMAIL PROTECTED]> writes: > sub func { > my( $foo, @bar ) = @_ ; > blah ; > } > > becomes: > > sub func( $foo, @bar ) { > blah ; > } I also hope that sub func : method { my( $self, $foo, @b

Re: New Group proposed: subs (was Re: named parameters)

On Fri, Aug 04, 2000 at 01:36:02AM -0400, Uri Guttman wrote: >it looks like typechecking and named params should fork off into a subs >subgroup. all of you with an itch to write an rfc, here is your chance. Anyone want to put their hand up as a chair of such a sublist? Damian's got the closest r

Re: New Group proposed: subs (was Re: named parameters)

Before anyone writes an RFC on names sub parameters, they should look at the archives of perl5-porters where it has been discussed a fair amount. A sample of what appeared to be rough-consensus syntax then: sub myfoo(Dog $spot : alias, String $str : readonly, $bar); Note the (more-or-le

New Group proposed: subs (was Re: named parameters)

named parameters seem to be a popular item. i haven't seen much more than a simple example syntax. how would the named params map onto or modify @_? would the equivilent perl5 code just be sub func { my( $foo, @bar ) = @_ ; blah ; } becomes:

Re: named parameters

> Nathan Wiger wrote: > > Because it has opportunity for bloat, I would suggest it should be in a > > pragma: > > > >use strict 'prototypes'; > > Bloat? What bloat? I don't want to *bloat* all my programs by sticking > a zillion pragmas in just to turn on all the features that makes Perl 6 >

Re: named parameters

Nathan Wiger wrote: > Because it has opportunity for bloat, I would suggest it should be in a > pragma: > >use strict 'prototypes'; Bloat? What bloat? I don't want to *bloat* all my programs by sticking a zillion pragmas in just to turn on all the features that makes Perl 6 different from Pe

Re: named parameters

On Fri, 4 Aug 2000, Damian Conway wrote: >> > Fair enough. If we were going to do it I would like to see it extend to: >> > >> > sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) { >> > >> > } >> >> Is there an RFC for this yet? If not, I think there needs to be. I

Re: named parameters

> > Fair enough. If we were going to do it I would like to see it extend to: > > > > sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) { > > > > } > > Is there an RFC for this yet? If not, I think there needs to be. I think > this would be really cool. I'll have a pro

Re: named parameters

> Fair enough. If we were going to do it I would like to see it extend to: > > sub test ( $x, @y:[N], %z, $fh:isa(IO::Handle) ) { > > } Is there an RFC for this yet? If not, I think there needs to be. I think this would be really cool. Because it has opportunity for bloat, I would suggest i

Re: named parameters

I have an RFC coming on this. (I know, I know, I keep promising, but none appear. I'll unload the first 10 or so later today, the gods willing) Damian

Re: named parameters

On Fri, 4 Aug 2000, Simon Cozens wrote: > On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote: > > Reading through the docs for perl prototypes I see that there is a > > reference to "named parameters" being a possibility in future versions of > > perl. > > > > Does anyone have a more co

Re: named parameters

On Thu, Aug 03, 2000 at 09:39:30AM -1000, Tim Jenness wrote: > Reading through the docs for perl prototypes I see that there is a > reference to "named parameters" being a possibility in future versions of > perl. > > Does anyone have a more concrete example of what was intended there? sub mari

Re: named parameters

> Reading through the docs for perl prototypes I see that there is a > reference to "named parameters" being a possibility in future versions of > perl. > > Does anyone have a more concrete example of what was intended there? (I'm > assuming that since it was mentioned that ther