[tpm] Is there a three-way version of...

[Uri Guttman]

>>>>> "SF" == Shaun Fryer <sfryer at sourcery.ca> writes:

  >> i generally don't like using shift on @_ and prefer to assign it.
  SF> True for complex stuff. My feeling is that when it's a very short
  SF> method (one liner), like a simple accessor, shift is faster (from
  SF> benchmarks I've seen) and not unclear/unmaintainable. For instance...

actually shift isn't faster. shift has to copy the data and also modify
a pointer in @_. assigning @_ to a list only needs to do the copy. and
multiple assignments with shift is slower than a single list assignment
from @_. a general rule of thumb (though easily broken) is that the less
perl code the faster. this is because most perl ops take about the same
amount of time and the op loop itself is the main overhead.

now the extreme case of reducing perl code to an absolute minimum
(called golfing) is bad too as it becomes unmaintainable. so there is a
happy balance to be found. less code is also easier to see with more
real code on the screen as you have fewer lines.

	my( $foo, $bar, $baz ) = @_

vs

	my $foo = shift ;
	my $bar = shift ;
	my $baz = shift ;

so why would you waste valuable vertical spacing on just getting args
from @_?

those are some of the reasons i don't like shift on @_ (except where it
really does help in some interesting cases).

uri

-- 
Uri Guttman  ------  uri at stemsystems.com  --------  http://www.sysarch.com --
-----  Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com ---------