Re: Function parameter passing (was: Re: limit the list)
* Bart Lateur <[EMAIL PROTECTED]> [2002-11-25 09:10]: > It is because it comes into the realm of undefined > behaviour. What it does is execution-order dependent, in > the least. Ah, but in Perl, this order is defined. The following is guaranteed to work: select((select(FH), $|++)[0]); If the order were not specified, it couldn't. > my($x, $y, $z) = ($i++, $i++, $i++); This has extra side effects besides the explicit effects, that's why it doesn't work out well. You need to be aware of more than the (explicitly specified) order of execution for the explicit effects in order to predict its outcome. > If you *need*, to modify the argument list, I'd first > think of the three separate shift statements, but more > likely, as Bernie Cosell suggested, I'd use the splice. Obviously, dito. :-) -- Regards, Aristotle
Re: Function parameter passing (was: Re: limit the list)
> You may be in luck, and it may do precisely what you want, but by the
> time you made sure it does, you've already wasted far too much time on
> it. Here is an example that mosty likely *not* do what you want:
>
> $i = 20;
> my($x, $y, $z) = ($i++, $i, $i++);
This is a great example, as only your warning hinted that it did
something other than:
x = 20
y = 21
z = 21
i = 22
> As to what the next does,
>
> $i = 20;
> my($x, $y, $z) = ($i++, +$i, $i++);
>
> your guess is a good as any.
You are trying too hard to catch us out, the "+" just enforces scalar
context so "$i" and "+$i" are identical - and thus we can easily
conclude it is the same as the last example.
Here is a good addition to Bart's examples:
my $i = 20;
my ($x, $y, $z) = ($i++, -$i, $i++);
print "$x $y $z\n";
Understanding the other examples... can you guess what does it prints?
Now, it appears that perl's evaluation order is accident rather than
design - so you SHOULD NOT rely on it. Avoid causing side-effects on
variables you use more than once... including the multiple use of shift
in assignment.
Jonathan Paton
=
s''! v+v+v+v+ J r e Ph+h+h+h+ !s`\x21`~`g,s`^ . | ~.*``mg,$v=q.
P ! v-v-v-v- u l r e r h-h-h- !12.,@.=m`.`g;do{$.=$2.$1,$.=~s`h
E ! v+v+v+ s k e h+h+ !`2`x,$.=~s`v`31`,print$.[$v+=$.]
R ! v-v- t H a c h h- !}while/([hv])([+-])/g;print"\xA"
L ! A n o t !';$..=$1while/([^!]*)$/mg;eval$.
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: Function parameter passing (was: Re: limit the list)
On Wed, 20 Nov 2002 14:43:07 +0100, Abigail wrote:
>> >sub commify
>> >{
>> >my ( $max, $sep, $end ) = ( shift, shift, shift );
>> ...
>> >}
>>
>> Wow! Hold it! Am I the only one who finds this absurd? More than one
>> shift on the same array in one single expressing, sounds like bad style
>> to me. Comments?
>
>
>Why is that bad style? Many times when people say it's bad style,
>it's just a case of "beauty is in the eye of the beholder".
>However, sometimes a style is bad because it's error-prone,
>confusing, similar to common idiom but doing something else,
>or inefficient. But I don't think any of them applies to this
>particular example.
>Bart, can you explain why this is bad style? Or is it just your
>personal preference?
It is because it comes into the realm of undefined behaviour. What it
does is execution-order dependent, in the least. It makes the programmer
think too hard on what it does. It is as bad as
my($x, $y, $z) = ($i++, $i++, $i++);
You may be in luck, and it may do precisely what you want, but by the
time you made sure it does, you've already wasted far too much time on
it. Here is an example that mosty likely *not* do what you want:
$i = 20;
my($x, $y, $z) = ($i++, $i, $i++);
As to what the next does,
$i = 20;
my($x, $y, $z) = ($i++, +$i, $i++);
your guess is a good as any.
As for an alternative, my first choice would be the simple array
assignment:
my ( $max, $sep, $end ) = @_;
If you *need*, to modify the argument list, I'd first think of the three
separate shift statements, but more likely, as Bernie Cosell suggested,
I'd use the splice.
my ( $max, $sep, $end ) = splice @_, 0, 3;
If this stings your eyes, may I suggest adding a optional second
argument to shift(), a number of items to shift, as
my ( $max, $sep, $end ) = shift @_, 3;
In scalar context, shift() when used with it could return the last item
of the shifted out list.
--
Bart.
Re: Function parameter passing (was: Re: limit the list)
On 21/11/2002 09:49:59 "Jonathan E. Paton" wrote: [snip: order of evaluation] > >Now, many "Perl" experts will have experience in other languages, such as C >where this is suicidal for portable code. C doesn't specify order, so that >the order of evaluation can be changed for optimisation. > I had to fix code once which behaved differently when compiled with different C compilers, because different compilers chose different order of evaluation (as they are entitled to do). It was NOT fun (not even in C). -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: [EMAIL PROTECTED]http://www.sophos..com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933
Re: Function parameter passing (was: Re: limit the list)
> > >> [EMAIL PROTECTED] (Abigail) writes:
> > >>> On Wed, Nov 20, 2002 at 11:42:43AM +0100, Bart Lateur wrote:
> > On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
> >
> > > sub commify
> > > {
> > > my ( $max, $sep, $end ) = ( shift, shift, shift );
> > ...
> > > }
> >
> > Wow! Hold it! Am I the only one who finds this absurd? More than one
> > shift on the same array in one single expressing, sounds like bad style
> > to me. Comments?
> > >>>
> > >>> Why is that bad style? Many times when people say it's bad style,
> > >>> it's just a case of "beauty is in the eye of the beholder".
> > >>
> > >> It forces the reader to think about associativity and order of evaluation.
> > >> If you've been bitten by unexpected outcomes before you might have to
> > >> try it to make sure it does what you think.
> > >>
> > >> I've used shift, shift before, so I already know. But it would be unfair
> > >> to foist on a junior maintenance programmer, IMHO.
> > >
> > >Associativity?
> >
> > Of the commas. A suitably paranoid programmer is going to wonder whether
> > the results will occur in the expected order if they've not tried before.
> > It won't occur to a novice. And an expert will already know. But someone
> > in between may wonder.
>
> How does an expert know? You say you know because you have tried it. I
> think I know for the same reason, and because I have read the perly.y
> and op.c, but I wouldn't want to stake anything particularly important
> on it.
Agreed. In C, the three shifts could be evaluated in several ways:
1: Shift 1, Shift 2, Shift 3
2: Shift 1, Shift 3, Shift 2
3: Shift 2, Shift 1, Shift 3
4: Shift 2, Shift 3, Shift 2
5: Shift 3, Shift 1, Shift 2
6: Shift 3, Shift 2, Shift 1
which is factorial(number of arguments) - although most compilers take the
first approach. Relying on this order in C is non-portable between
compilers - I've read documentation for one compiler that said it took middle
first (i.e. either 3,4) which is very counter-intutive.
Now, many "Perl" experts will have experience in other languages, such as C
where this is suicidal for portable code. C doesn't specify order, so that
the order of evaluation can be changed for optimisation.
E&OE
Jonathan Paton
=
s''! v+v+v+v+ J r e Ph+h+h+h+ !s`\x21`~`g,s`^ . | ~.*``mg,$v=q.
P ! v-v-v-v- u l r e r h-h-h- !12.,@.=m`.`g;do{$.=$2.$1,$.=~s`h
E ! v+v+v+ s k e h+h+ !`2`x,$.=~s`v`31`,print$.[$v+=$.]
R ! v-v- t H a c h h- !}while/([hv])([+-])/g;print"\xA"
L ! A n o t !';$..=$1while/([^!]*)$/mg;eval$.
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: Function parameter passing (was: Re: limit the list)
On Wed, Nov 20, 2002 at 08:46:25PM -, Peter Scott wrote:
> [EMAIL PROTECTED] (Steven Lembark) writes:
> >-- Peter Scott <[EMAIL PROTECTED]>
> >> In article <[EMAIL PROTECTED]>,
> >> [EMAIL PROTECTED] (Abigail) writes:
> >>> On Wed, Nov 20, 2002 at 11:42:43AM +0100, Bart Lateur wrote:
> On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
>
> > sub commify
> > {
> >my ( $max, $sep, $end ) = ( shift, shift, shift );
> ...
> > }
>
> Wow! Hold it! Am I the only one who finds this absurd? More than one
> shift on the same array in one single expressing, sounds like bad style
> to me. Comments?
> >>>
> >>> Why is that bad style? Many times when people say it's bad style,
> >>> it's just a case of "beauty is in the eye of the beholder".
> >>
> >> It forces the reader to think about associativity and order of evaluation.
> >> If you've been bitten by unexpected outcomes before you might have to
> >> try it to make sure it does what you think.
> >>
> >> I've used shift, shift before, so I already know. But it would be unfair
> >> to foist on a junior maintenance programmer, IMHO.
> >
> >Associativity?
>
> Of the commas. A suitably paranoid programmer is going to wonder whether
> the results will occur in the expected order if they've not tried before.
> It won't occur to a novice. And an expert will already know. But someone
> in between may wonder.
How does an expert know? You say you know because you have tried it. I
think I know for the same reason, and because I have read the perly.y
and op.c, but I wouldn't want to stake anything particularly important
on it.
Can anyone point to any documentation which describes the order of
evaluation within a list? The order of evaluation for the comma
operator in a scalar context is explicitly defined (which is just as
well), but I can't find such a guarantee in list context, which seems
strange if there were such a guarantee, since it would likely be found
immediately after the guarantee for scalar context in perlop. Neither
can I find any tests for this, but I can find one core module which
depends on this left to right order of evaluation.
I suspect this order is unlikely to change because
a. Perl tries hard to DWIM, and left to right is probably what most
people mean.
b. Perl tries hard to be backwards compatible, even when people have
done things that they probably shouldn't have.
There are no guarantees on the order of evaluation within an expression.
Are there within a list?
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Function parameter passing (was: Re: limit the list)
[Posted and mailed]
In article <23862.1037824657@[192.168.200.4]>,
[EMAIL PROTECTED] (Steven Lembark) writes:
>
>
>-- Peter Scott <[EMAIL PROTECTED]>
>
>> In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (Abigail) writes:
>>> On Wed, Nov 20, 2002 at 11:42:43AM +0100, Bart Lateur wrote:
On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
> sub commify
> {
> my ( $max, $sep, $end ) = ( shift, shift, shift );
...
> }
Wow! Hold it! Am I the only one who finds this absurd? More than one
shift on the same array in one single expressing, sounds like bad style
to me. Comments?
>>>
>>> Why is that bad style? Many times when people say it's bad style,
>>> it's just a case of "beauty is in the eye of the beholder".
>>
>> It forces the reader to think about associativity and order of evaluation.
>> If you've been bitten by unexpected outcomes before you might have to
>> try it to make sure it does what you think.
>>
>> I've used shift, shift before, so I already know. But it would be unfair
>> to foist on a junior maintenance programmer, IMHO.
>
>Associativity?
Of the commas. A suitably paranoid programmer is going to wonder whether
the results will occur in the expected order if they've not tried before.
It won't occur to a novice. And an expert will already know. But someone
in between may wonder.
>This just takes the first three items
>off the arguments (leaving the rest of it on @_),
>puts them on a list, and assigns it. I've had more
>problems with junior programmers botching the order
>of separate assignments (or more often deleting one
>out of the middle) than mis-understanding how shift
>works. Even fewer of the people walking around
>understand splice (which is where I came up with the
>list-of-shifts).
I don't think splice is that bad; it's a straightforward function.
You have to make sure the count matches the number of elements on the
left, just as you have to match the number of `shift's.
An argument this subjective is unlikely to reach a definitive resolution.
--
Peter Scott
Re: Function parameter passing (was: Re: limit the list)
-- "A. Pagaltzis" <[EMAIL PROTECTED]> * Andrew Molyneux <[EMAIL PROTECTED]> [2002-11-20 18:25]: A. Pagaltzis wrote: > Enter splice. > > my ($max, $sep, $end) = splice @_, 0, 3; That has brevity, certainly, but for legibility, I think I prefer Steven's original (shift,shift,shift) Really? I find the splice version a lot easier on the easier on the eyes. But that's a matter of taste. How many parameters do I have here? shift, shift, shift, shift, shift, shift, shift, shift, shift, shift; .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. And this time? splice @_, 0, 10; Point in case, scalability. And it obviously makes sense to use the splice at some point. I am unlikely to use my ( $a ) = splice @_, 0, 1; for example. Probably after 3-4 arguments I'd give up and use splice or at some point pass the thing as a hash[ref] and use named parameters. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Function parameter passing (was: Re: limit the list)
-- Philip Newton <[EMAIL PROTECTED]>
hat happens when you do
@a = qw( foo bar bletch blort bim bam blort );
my ( $a, $b, $c ) = @a;
?
Obviously a better example. Point is that $c is one
item on the list, but $a, $b, and $c are still on the
list. Given that the original code used the conteints
of @_ as fodder for the map it seemed more effective
to grab the values off the front rather than assign
them. So that using:
my( $a, $b, $c ) = @_
...
map
{
...
}
@_
would not provide the same result as shifting the first
three items off of @_. You could obviously splice the
three items off in a void context after the assignment,
but at that point it seems easier to just assign the
shifts and be done with it in one place.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
Re: Function parameter passing (was: Re: limit the list)
-- Peter Scott <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Abigail) writes:
On Wed, Nov 20, 2002 at 11:42:43AM +0100, Bart Lateur wrote:
On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
> sub commify
> {
> my ( $max, $sep, $end ) = ( shift, shift, shift );
...
> }
Wow! Hold it! Am I the only one who finds this absurd? More than one
shift on the same array in one single expressing, sounds like bad style
to me. Comments?
Why is that bad style? Many times when people say it's bad style,
it's just a case of "beauty is in the eye of the beholder".
It forces the reader to think about associativity and order of evaluation.
If you've been bitten by unexpected outcomes before you might have to
try it to make sure it does what you think.
I've used shift, shift before, so I already know. But it would be unfair
to foist on a junior maintenance programmer, IMHO.
Associativity? This just takes the first three items
off the arguments (leaving the rest of it on @_),
puts them on a list, and assigns it. I've had more
problems with junior programmers botching the order
of separate assignments (or more often deleting one
out of the middle) than mis-understanding how shift
works. Even fewer of the people walking around
understand splice (which is where I came up with the
list-of-shifts).
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
Re: Function parameter passing (was: Re: limit the list)
* Andrew Molyneux <[EMAIL PROTECTED]> [2002-11-20 18:25]: > A. Pagaltzis wrote: > > Enter splice. > > > > my ($max, $sep, $end) = splice @_, 0, 3; > > That has brevity, certainly, but for legibility, I think I > prefer Steven's original (shift,shift,shift) Really? I find the splice version a lot easier on the easier on the eyes. But that's a matter of taste. How many parameters do I have here? shift, shift, shift, shift, shift, shift, shift, shift, shift, shift; .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. And this time? splice @_, 0, 10; Point in case, scalability. -- Regards, Aristotle
Re: Function parameter passing (was: Re: limit the list)
On Wed, 20 Nov 2002 13:33:27 -0600, [EMAIL PROTECTED] (Steven Lembark)
wrote:
> -- Philip Newton <[EMAIL PROTECTED]>
>
> > On Wed, 20 Nov 2002 10:35:11 -0600, [EMAIL PROTECTED] (Steven Lembark)
> > wrote:
> >
> >> -- Andrew Molyneux <[EMAIL PROTECTED]>
> >>
> >> > I'd probably do:
> >> > my ($max, $sep, $end) = @_;
> >>
> >> Yes, becuase if you did it this way you'd get $end equal
> >> to the integer coult of the number of list arguments passed
> >> plus one for the end value.
> >
> > Huh? $end gets assigned $_[2]. I'm not sure where you get an "integer
> > coult" from.
>
> Look up what happens to arrays in a scalar context.
There's no scalar context involved as I understand it. Since you have
parentheses, it's a list context assignment.
> Or try in the debugger:
>
> my ( $a, $b, $c ) = qw( foo bar bletch blort bim bam blort );
>
> what do yo get for $c?
"bletch". Well, at least if I omit the "my" and do only ($a, $b, $c) =
qw( ... ). Possibly a scoping problem with my debugger: it works when I
type it straight into Perl, without the debugger.
Which version of Perl are you using? qw() used to be implemented using
split(), which pays attention to the number of arguments available for
assignment on the left-hand side (unlike other list assignment). I
believe this was changed round about 5.6.0 to expand qw(a b c) to the
list ('a', 'b', 'c') at compile-time rather than at run-time with a
hidden split. Maybe that's what caused you problems?
And as Aristotle said - that's not an array, so it's not the same thing.
What happens when you do
@a = qw( foo bar bletch blort bim bam blort );
my ( $a, $b, $c ) = @a;
?
Cheers,
Philip
Re: Function parameter passing (was: Re: limit the list)
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Abigail) writes:
>On Wed, Nov 20, 2002 at 11:42:43AM +0100, Bart Lateur wrote:
>> On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
>>
>> >sub commify
>> >{
>> >my ( $max, $sep, $end ) = ( shift, shift, shift );
>> ...
>> >}
>>
>> Wow! Hold it! Am I the only one who finds this absurd? More than one
>> shift on the same array in one single expressing, sounds like bad style
>> to me. Comments?
>
>Why is that bad style? Many times when people say it's bad style,
>it's just a case of "beauty is in the eye of the beholder".
It forces the reader to think about associativity and order of evaluation.
If you've been bitten by unexpected outcomes before you might have to
try it to make sure it does what you think.
I've used shift, shift before, so I already know. But it would be unfair
to foist on a junior maintenance programmer, IMHO.
--
Peter Scott
Re: Function parameter passing (was: Re: limit the list)
> >> > I'd probably do:
> >> > my ($max, $sep, $end) = @_;
> >>
> >> Yes, becuase if you did it this way you'd get $end equal
> >> to the integer coult of the number of list arguments passed
> >> plus one for the end value.
> >
> > Huh? $end gets assigned $_[2]. I'm not sure where you get an "integer
> > coult" from.
>
> Look up what happens to arrays in a scalar context.
>
> Or try in the debugger:
>
> my ( $a, $b, $c ) = qw( foo bar bletch blort bim bam blort );
>
> what do yo get for $c?
Not what you expected... a slight change avoids this:
my ( $a, $b, $c, undef) = qw( foo bar bletch blort bim bam blort );
Jonathan Paton
=
s''! v+v+v+v+ J r e Ph+h+h+h+ !s`\x21`~`g,s`^ . | ~.*``mg,$v=q.
P ! v-v-v-v- u l r e r h-h-h- !12.,@.=m`.`g;do{$.=$2.$1,$.=~s`h
E ! v+v+v+ s k e h+h+ !`2`x,$.=~s`v`31`,print$.[$v+=$.]
R ! v-v- t H a c h h- !}while/([hv])([+-])/g;print"\xA"
L ! A n o t !';$..=$1while/([^!]*)$/mg;eval$.
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
RE: Function parameter passing (was: Re: limit the list)
> -Original Message- > From: Steven Lembark [mailto:[EMAIL PROTECTED]] > -- Philip Newton <[EMAIL PROTECTED]> > > On Wed, 20 Nov 2002 10:35:11 -0600, [EMAIL PROTECTED] (Steven > > Lembark) wrote: > >> -- Andrew Molyneux <[EMAIL PROTECTED]> > >> > >> > I'd probably do: > >> > my ($max, $sep, $end) = @_; > >> > >> Yes, becuase if you did it this way you'd get $end equal > >> to the integer coult of the number of list arguments passed plus one > >> for the end value. > > > > Huh? $end gets assigned $_[2]. I'm not sure where you get an "integer > > coult" from. > > Look up what happens to arrays in a scalar context. > > Or try in the debugger: > > my ( $a, $b, $c ) = qw( foo bar bletch blort bim bam blort ); > > what do yo get for $c? What crack pipe yo' smokin' home's? $c ain't no integer coult, 'at $c be a nasty "bletch". d:\>perl -e "my ( $a, $b, $c ) = qw( foo bar bletch blort bim bam blort );print$c" bletch d:\>perl -v This is perl, v5.6.1 built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) --- Registered Office: Marks & Spencer p.l.c Michael House, Baker Street, London, W1U 8EP Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. The registered office of Marks and Spencer Financial Services PLC, Marks and Spencer Unit Trust Management Limited, Marks and Spencer Life Assurance Limited and Marks and Spencer Savings and Investments Limited is Kings Meadow, Chester, CH99 9FB.
Re: Function parameter passing (was: Re: limit the list)
* Steven Lembark <[EMAIL PROTECTED]> [2002-11-20 20:51]: > Look up what happens to arrays in a scalar context. > > my ( $a, $b, $c ) = qw( foo bar bletch blort bim bam blort ); > > what do yo get for $c? 'bletch' - and that's not an array there. -- Regards, Aristotle
Re: Function parameter passing (was: Re: limit the list)
-- Philip Newton <[EMAIL PROTECTED]> On Wed, 20 Nov 2002 10:35:11 -0600, [EMAIL PROTECTED] (Steven Lembark) wrote: -- Andrew Molyneux <[EMAIL PROTECTED]> > I'd probably do: > my ($max, $sep, $end) = @_; Yes, becuase if you did it this way you'd get $end equal to the integer coult of the number of list arguments passed plus one for the end value. Huh? $end gets assigned $_[2]. I'm not sure where you get an "integer coult" from. Look up what happens to arrays in a scalar context. Or try in the debugger: my ( $a, $b, $c ) = qw( foo bar bletch blort bim bam blort ); what do yo get for $c? -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Function parameter passing (was: Re: limit the list)
On Wed, 20 Nov 2002 10:35:11 -0600, [EMAIL PROTECTED] (Steven Lembark) wrote: > -- Andrew Molyneux <[EMAIL PROTECTED]> > > > I'd probably do: > > my ($max, $sep, $end) = @_; > > Yes, becuase if you did it this way you'd get $end equal > to the integer coult of the number of list arguments passed > plus one for the end value. Huh? $end gets assigned $_[2]. I'm not sure where you get an "integer coult" from. > Notice the usage: > > my $string = commify 90, ', ', 'etc...', @names; Those parameters get flattened into a list @_. @names doesn't know that there's an assignment to a scalar in the subroutine; it gives up its identity and becomes part of the list. And anyway, it's a list context assignment. The first three elements of @_ get assigned to $max, $sep, and $end (respectively); all further elements get ignored. Similar to my ($ss, $mm, $hh) = localtime; or my ($foo, $bar, baz) = (1 .. 10); > The other problem is that even if there were only three > arguments being passed in you have to check the count > before making the assignment and croak on @_ != 3 in > order to avoid an extra parameter causing $end to > become an integer count. Why? IDGI. Cheers, Philip
Re: Function parameter passing (was: Re: limit the list)
Steven Lembark wrote: > Yes, becuase if you did it this way you'd get $end equal > to the integer coult of the number of list arguments passed > plus one for the end value. Notice the usage: > > my $string = commify 90, ', ', 'etc...', @names; > D'oh! (slaps head). Serves me right for not reading your code properly. I blame a lack of caffeine. A. Pagaltzis wrote: > Enter splice. > > my ($max, $sep, $end) = splice @_, 0, 3; That has brevity, certainly, but for legibility, I think I prefer Steven's original (shift,shift,shift) Andrew
Re: Function parameter passing (was: Re: limit the list)
* Steven Lembark <[EMAIL PROTECTED]> [2002-11-20 17:35]: > Yes, becuase if you did it this way you'd get $end equal > to the integer coult of the number of list arguments passed > plus one for the end value. Notice the usage: > > my $string = commify 90, ', ', 'etc...', @names; > > The other problem is that even if there were only three > arguments being passed in you have to check the count > before making the assignment and croak on @_ != 3 in > order to avoid an extra parameter causing $end to > become an integer count. Enter splice. my ($max, $sep, $end) = splice @_, 0, 3; -- Regards, Aristotle
Re: Function parameter passing (was: Re: limit the list)
-- Andrew Molyneux <[EMAIL PROTECTED]> Wow! Hold it! Am I the only one who finds this absurd? More than one shift on the same array in one single expressing, sounds like bad style to me. Comments? You're not the only one. I'd probably do: my ($max, $sep, $end) = @_; but I'd love to know if Steven had a specific reason for doing it the other way. Yes, becuase if you did it this way you'd get $end equal to the integer coult of the number of list arguments passed plus one for the end value. Notice the usage: my $string = commify 90, ', ', 'etc...', @names; The other problem is that even if there were only three arguments being passed in you have to check the count before making the assignment and croak on @_ != 3 in order to avoid an extra parameter causing $end to become an integer count. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Function parameter passing (was: Re: limit the list)
-- Bart Lateur <[EMAIL PROTECTED]>
On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
sub commify
{
my ( $max, $sep, $end ) = ( shift, shift, shift );
...
}
Wow! Hold it! Am I the only one who finds this absurd? More than one
shift on the same array in one single expressing, sounds like bad style
to me. Comments?
I've been using multiple shift's for years. Puts all of
the local var's in one place and makes it much harder for
edit errors to remove or re-order the parameters.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
RE: Function parameter passing (was: Re: limit the list)
On 20 Nov 2002 at 13:43, Moran, Matthew wrote: > Abigail wondered: > > > Why is that bad style? Many times when people say it's bad style, > > it's just a case of "beauty is in the eye of the beholder". > > > > Strikes me that instead of using one move to assign the variables, it's > using three. Just so. If the *intent* of the code is to remove the first three elements from @_ and assign them to variables[*] isn't the clearest way to express the intent just to do: my ($a, $b, $c) = splice (@_,0,3) It seems to express the *exact* semantics desired [remove the elements from @_ and assign those to the vbls), and to my eye does it more clearly than (shift, shift, shift) does. [*] NB: this has *different* semantics than doing my ($v1, $v2, $v3) = @_ -- I'm assuming here that the modification to @_ is actually necessary [if not, then it is not bad form on syntatic grounds, but because it is doing something unnecessary and potentially confusing]. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <--
RE: Function parameter passing (was: Re: limit the list)
Abigail wondered: > Why is that bad style? Many times when people say it's bad style, > it's just a case of "beauty is in the eye of the beholder". > Strikes me that instead of using one move to assign the variables, it's using three. Matt " This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message ".
RE: Function parameter passing (was: Re: limit the list)
Joachim suggested:
> >Wow! Hold it! Am I the only one who finds this absurd? More than one
> >shift on the same array in one single expressing, sounds
> like bad style
> >to me. Comments?
>
> In one of my programs, this would be
>
> sub commify {
> my $max = shift;
> my $sep = shift;
> my $end = shift;
>
> ...
> }
>
> better or even worse in your view?
Clearer, but just as bad IMHO. I've always done it as
sub subroutine(
my ($list, &of, $variables) = @_;
# rest of code here
}
It's how it's always shown in the Cookbook & what have you.
Matt
" This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only for
the person to whom it is addressed. If you are not the intended recipient, you
are not authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error, please
notify the sender immediately and delete all copies of this message ".
Re: Function parameter passing (was: Re: limit the list)
On Wed, Nov 20, 2002 at 11:42:43AM +0100, Bart Lateur wrote:
> On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
>
> >sub commify
> >{
> > my ( $max, $sep, $end ) = ( shift, shift, shift );
> ...
> >}
>
> Wow! Hold it! Am I the only one who finds this absurd? More than one
> shift on the same array in one single expressing, sounds like bad style
> to me. Comments?
Why is that bad style? Many times when people say it's bad style,
it's just a case of "beauty is in the eye of the beholder".
However, sometimes a style is bad because it's error-prone,
confusing, similar to common idiom but doing something else,
or inefficient. But I don't think any of them applies to this
particular example.
Bart, can you explain why this is bad style? Or is it just your
personal preference?
Abigail
Re: Function parameter passing (was: Re: limit the list)
* Andrew Molyneux <[EMAIL PROTECTED]> [2002-11-20 12:47]: > You're not the only one. I'd probably do: > my ($max, $sep, $end) = @_; me too > but I'd love to know if Steven had a specific reason > for doing it the other way. There doesn't seem to be any here. -- Regards, Aristotle
Re: Function parameter passing (was: Re: limit the list)
> Wow! Hold it! Am I the only one who finds this absurd? More than one
> shift on the same array in one single expressing, sounds like bad style
> to me. Comments?
You're not the only one. I'd probably do:
my ($max, $sep, $end) = @_;
but I'd love to know if Steven had a specific reason for doing it the
other way.
Andrew
- Original Message -
From: "Bart Lateur" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 10:42 AM
Subject: Function parameter passing (was: Re: limit the list)
> On Wed, 20 Nov 2002 04:10:02 -0600, Steven Lembark wrote:
>
> >sub commify
> >{
> > my ( $max, $sep, $end ) = ( shift, shift, shift );
> ...
> >}
>
> Wow! Hold it! Am I the only one who finds this absurd? More than one
> shift on the same array in one single expressing, sounds like bad style
> to me. Comments?
>
> --
> Bart.
>
