On Wed, Mar 12, 2003 at 12:18:33PM +1100, Damian Conway wrote:
Various folks have suggested that the default assignment syntax:
sub foo(?$bar is copy = 1) {...}
be considered merely a shorthand for something like:
sub foo(?$bar is copy is default(1)) {...}
thereby allowing:
Nicholas Clark wrote:
On Wed, Mar 12, 2003 at 12:18:33PM +1100, Damian Conway wrote:
The design team has already considered this idea, and my problem
with it then (and now) is that it's inconsistent with other forms
of variable declaration:
my sub foo( ?$bar is constant = 1 )
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up to allow earmarked contributions?
brad
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up to allow earmarked contributions?
Dunno. But
At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up to
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all
the
summaries after all. I just hope that a chunk of it ends up in
At 8:07 AM -0800 3/14/03, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes [EMAIL PROTECTED] writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all
the
summaries
Mark J. Reed wrote:
2- Yeah! ... umm, are we *paying* you for this?
Not any more. In fact, like Larry and several others on the design team,
I'm now paying for the privilege of doing it. ;-)
If the TPF isn't supporting you folks anymore, what's the best
way for those of us out in the field to
Damian Conway [EMAIL PROTECTED] writes:
And don't write off the Perl Foundation yet. TPF is just about to do a
survey of what people think they (TPF) should be funding. If you
believe Larry and/or myself and/or other members of the design or
implementation teams are worth sponsoring, I'd
On Wednesday, March 12, 2003, at 04:07 PM, Piers Cawley wrote:
Michael Lazzaro [EMAIL PROTECTED] writes:
Can we get a final answer, for the (documented) record?
@list is variadic
@list is slurpy
@list is greedy
@list is slurpificatious
@list is slurptacular
@list is
Simon Cozens [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Piers Cawley) writes:
Well... I've finally got my act together and invoice ORA for the
summary money that's destined for TPF and I would dearly love to see
all of that lump of cash go to Larry.
Yay, another attempt to confuse me and
Brent Dax writes:
Damian Conway:
# Brent Dax wrote:
#
#method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
#
# Yikes. And I thought we were trying to get *away* from
# line noise?
# :^)
However that's an example explicitly demonstrating all the
--- Damian Conway [EMAIL PROTECTED] wrote:
Various folks have suggested that the default assignment syntax:
sub foo(?$bar is copy = 1) {...}
be considered merely a shorthand for something like:
sub foo(?$bar is copy is default(1)) {...}
thereby allowing:
sub
On Wed, Mar 12, 2003 at 01:45:53PM +1100, Damian Conway wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
Larry
Austin Hastings wrote:
The design team has already considered this idea, and my problem
with it then (and now) is that it's inconsistent with other forms
of variable declaration:
my sub foo( ?$bar is constant = 1 ) {...} # OKAY
my $bar is constant = 1; # OKAY
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
Riiight! Thank-you, General Haig.
Of course, Cis variadic (my own
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
On Wed, Mar 12, 2003 at 11:23:56AM -0800, Michael Lazzaro wrote:
: On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
: Larry wrote:
:
: : I agree. As long as it's not Cis slurpy!
: Of course not. We're trying to encourage the use of line noise,
: and discourage the use of the long
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
The design team has already considered this idea, and my problem
with it then (and now) is that it's inconsistent with other forms
of variable declaration:
my sub foo( ?$bar is constant = 1 ) {...} # OKAY
Larry wrote:
: Can we get a final answer, for the (documented) record?
No. I have to wait till Damian isn't looking.
Ah, so it's *never* going to be revealed?
;-)
Damian
Austin Hastings wrote:
But this isn't really a cognitive dissonance,
I think it is. Constructs that mean two different things in two different
contexts are always dissonances. Mind you, humans are normally quite good at
coping with that kind of contextually sensitive dissonance. Right up to
--- Damian Conway [EMAIL PROTECTED] wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
Riiight!
On 2003-03-13 at 05:44:09, Damian Conway wrote:
2- Yeah! ... umm, are we *paying* you for this?
Not any more. In fact, like Larry and several others on the design team,
I'm now paying for the privilege of doing it. ;-)
If the TPF isn't supporting you folks anymore, what's the best
way for
--- Mark J. Reed [EMAIL PROTECTED] wrote:
On 2003-03-13 at 05:44:09, Damian Conway wrote:
2- Yeah! ... umm, are we *paying* you for this?
Not any more. In fact, like Larry and several others on the design
team,
I'm now paying for the privilege of doing it. ;-)
If the TPF isn't
Michael Lazzaro [EMAIL PROTECTED] writes:
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one
--- Brent Dax [EMAIL PROTECTED] wrote:
method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
Yikes. And I thought we were trying to get *away* from line noise?
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is
The problem is that if you have multiple optional or named
parameters, things start getting uncomfortably prolix, and default
values end up a long way from their owners:
multi substr(Str $str, $from is optional = $CALLER::_,
$len is optional = Inf, $new is optional) {...}
Damian Conway:
# Brent Dax wrote:
#
# method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
#
# Yikes. And I thought we were trying to get *away* from
# line noise?
# :^)
#
# Seriously, can't we use something rather prettier, like this?
#
# method
On Tuesday, March 11, 2003, at 08:41 AM, Brent Dax wrote:
Almost makes you wish for those backwards declarations from C that
computer scientists always gripe about, eh? :^) Well, what about
this?
multi substr(Str $str, $from = $CALLER::_ is optional, $len =
Inf is optional, $new is
Various folks have suggested that the default assignment syntax:
sub foo(?$bar is copy = 1) {...}
be considered merely a shorthand for something like:
sub foo(?$bar is copy is default(1)) {...}
thereby allowing:
sub foo(?$bar is default(1) is copy ) {...}
and hence (mirabile
Michael Lazzaro asked:
Are you concerned about having an Cis default() spelling at all
No, not at all. It really is a shorthand for a trait, after all, so it should
almost certainly have a trait name. Besides, Cis default is probably needed
for non-parameter variables too:
my %nickname
I don't know that that means we couldn't have an Cis default()
spelling, though. And Cis variadic (or something easier to spell)
for the * case. If we have Cis optional and Cis named, I think
it would be appropriate to have names for the other linenoise as
well.
I'd say please.
Brent Dax wrote:
method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
Yikes. And I thought we were trying to get *away* from line noise? :^)
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is optional, $namedop is named,
33 matches
Mail list logo
