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
On Mon, 25 Nov 2002 11:34:23 + (GMT), [EMAIL PROTECTED] wrote:
$i = 20;
my($x, $y, $z) = ($i++, $i, $i++);
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.
This isn't an issue of evaluation order. In the example above, perl
evaluates first $i++, then $i, then $i++, placing the results in a
list. Then the assignment is done. The reason $y becomes 22 is that
the *variable* $i is in the list (by reference, if you will), not the
*value* of $i. Only when the assignment is done is the value
accessed.
Keep in mind that perl passes parameters by reference, and almost all
operands act just like subroutine parameters. If you have:
sub aassign{ print \$_[$_] is $_[$_]\n for 0..$#_ }
$i = 20;
aassign($i++, $i, $i++)
you get:
$_[0] is 20
$_[1] is 22
$_[2] is 21
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)
* Andrew Molyneux [EMAIL PROTECTED] [2002-11-20 12:47]: You're not the only one. I'd probably do: my ($max, $sep, $end) = @_; aolme too/aol 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)
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)
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)
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: AW: Function parameter passing (was: Re: limit the list)
--- Pense, Joachim [EMAIL PROTECTED] wrote: Von: Moran, Matthew
[mailto:[EMAIL PROTECTED]]
Gesendet am: Mittwoch, 20. November 2002 14:41
Joachim suggested:
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.
Not *always*, I've seen my version explicitly suggested somewhere. The
advantage in my eyes is that you consume the input parameters so they are
gone when you read them. It is also easier to check in the end if there are
any left so too many were supplied.
You mean you saw it in the holy book itself: Programming Perl
(aka The Camel). Looking at page 374 we find:
sub TIEARRAY {
my $class = shift;
my $bound = shift;
confess usage: tie(\@array, 'BoundedArray', max_subscript)
if @_ || $bound =~ /\D/;
return bless { BOUND = $bound, DATA = [] }, $class;
}
To bring this back inline with the original discussion, I was thinking the
problem could be solved with a tied array. Starting at 372 it shouldn't
take long to implement the required code - left as an exercise for the
reader.
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: AW: Function parameter passing (was: Re: limit the list)
On Wed, 20 Nov 2002, Pense, Joachim wrote:
Bart Lateur [mailto:[EMAIL PROTECTED]] wrote:
(Mittwoch, 20. November 2002 11:43)
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?
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?
Better, but only if it makes sense to conditionally take values off the
calling stack, like this contrived example:
sub foo {
my $type = shift;
my $arg1 = shift;
my $arg2 = 0;
if ($type == 'APIv2') {
$arg2 = shift;
}
return $arg1 + $arg2;
}
A variation of this would be if, depending on the type, you might want
different names for a given element on the calling stack:
sub foo {
my $type = shift;
my $arg1 = shift;
if ($type == 'APIv2') {
my $adder = shift;
return $arg1 + $adder
} elsif ($type == 'APIv3') {
my $subtractor = shift;
return $arg1 - $subtractor;
}
return $arg1;
}
You might also do something like this to illustrate that depending on the
value of the first argument, we may not even care about any of the rest.
sub foo {
my $type = shift;
if ($type == 'APIv3') {
carp APIv3 unsupported\n;
return;
}
# perhaps do computationally intensive or transactional stuff here
# ..
my $arg1 = shift;
my $arg2 = 0;
if ($type == 'APIv2') {
$arg2 = shift;
}
return $arg1 + $arg2;
}
Granted, there's no performance benefit, but since certain variables
aren't introduced until after the conditional return case, it definitively
shows that those values aren't needed unless we pass the condition.
I think that using 'shift' as a little faucet that gives you stuff as you
need it is rather elegant.
--Jeremy
--
Jeremy Impson
Sr. Associate Network Engineer
Investigative Research Marketing
Lockheed Martin Systems Integration
email: [EMAIL PROTECTED]
phone: 607-751-5618
fax: 607-751-6025
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)
-- 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: AW: Function parameter passing (was: Re: limit the list)
-- Pense, Joachim [EMAIL PROTECTED]
Bart Lateur [mailto:[EMAIL PROTECTED]] wrote:
(Mittwoch, 20. November 2002 11:43)
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?
In one of my programs, this would be
sub commify {
my $max = shift;
my $sep = shift;
my $end = shift;
Until someone does
my $sep = shift;
my $max = shift;
my $end = shift;
or
my $sep = shift;
my $max = shift;
to it. Especially the former has caused people who work for
me pain, which is why I adopted the one-line method. That
or splice.
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
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)
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)
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 [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)
-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: AW: Function parameter passing (was: Re: limit the list)
On Wed, 20 Nov 2002 13:34:40 -
Pense, Joachim [EMAIL PROTECTED] wrote:
Bart Lateur [mailto:[EMAIL PROTECTED]] wrote:
(Mittwoch, 20. November 2002 11:43)
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?
In one of my programs, this would be
sub commify {
my $max = shift;
my $sep = shift;
my $end = shift;
...
}
I use this form too. it is more explicit and gives nice way to comment:
sub commify {
my $max = shift; # this is arg 1 blah
my $sep = shift; # arg two blah
my $end = shift; # arg III, actually takes hash reference to useless data :)
...
}
which is better than
my ( $max, # ala
$sep, # bala
$end ) # nica
= @_;
imo.
it is matter of taste of cource...
my ( ... ) = @_;
has the only advantage to be ~20% faster for large number of function call iterations.
finally:
sub nonsensessez
{
my $s = $_[0];
my $a = $_[1];
my $k = $_[2];
my $j = $_[3];
my $l = $_[4];
1;
}
combines the best from both forms above ( i.e. cna be commented, clean and
approx. as fast as `my ( ... ) = @_' thing.
P! Vladi.
better or even worse in your view?
Joachim
--
Vladi Belperchinov-Shabanski [EMAIL PROTECTED] [EMAIL PROTECTED]
Personal home page at http://www.biscom.net/~cade
DataMax Ltd. http://www.datamax.bg
Too many hopes and dreams won't see the light...
msg02736/pgp0.pgp
Description: PGP signature
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)
* 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)
-- 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)
-- 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: AW: Function parameter passing (was: Re: limit the list)
-- Vladi Belperchinov-Shabanski [EMAIL PROTECTED]
On Wed, 20 Nov 2002 13:34:40 -
Pense, Joachim [EMAIL PROTECTED] wrote:
Bart Lateur [mailto:[EMAIL PROTECTED]] wrote:
(Mittwoch, 20. November 2002 11:43)
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?
In one of my programs, this would be
sub commify {
my $max = shift;
my $sep = shift;
my $end = shift;
...
}
I use this form too. it is more explicit and gives nice way to comment:
sub commify {
my $max = shift; # this is arg 1 blah
my $sep = shift; # arg two blah
my $end = shift; # arg III, actually takes hash reference to useless
data :)
...
}
which is better than
my ( $max, # ala
$sep, # bala
$end ) # nica
= @_;
imo.
it is matter of taste of cource...
my ( ... ) = @_;
has the only advantage to be ~20% faster for large number of function
call iterations.
finally:
sub nonsensessez
{
my $s = $_[0];
my $a = $_[1];
my $k = $_[2];
my $j = $_[3];
my $l = $_[4];
1;
}
combines the best from both forms above ( i.e. cna be commented, clean and
approx. as fast as `my ( ... ) = @_' thing.
Only to the extent that you are not processing the remainder
of @_ after taking the fixed parameters -- that or you have
to remember to use the proper offset in a foreach or array
slice to access the argument array in for/map/grep.
--
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, 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
