On Dec 10, 2007 5:54 PM, <[EMAIL PROTECTED]> wrote:
snip
> Ok, but hold it a minute... I think I must have been unclear in that
> post because I wasn't saying I thought using undef there was the way
> to go, I did that to try to trip the same warning output. But it
> didn't (it caused a similar warning further along as expected) so I
> was saying that showed that $OutputFile being undefined was NOT the
> reason for the warning this thread was about. (thats probably as clear
> as mud too).
snip
Undefined values are allowed in logical tests, so using an undef in
them will not trip any warnings. You will get an undef warning when
you try to use an undefined value where a defined one is expected.
For instance:
my $foo;
my $bar = 5 + $foo; #this will trip a warning
my $baz = "the variable \$foo has the value $foo\n"; #this will trip a warning
snip
>
> > my $OutputFile = shift || "/home/reader/projects/perl/work/myfile";
> > die "<$OutputFile> cannot be found .. exiting\n" unless -f $OutputFile;
>
> Now there is something I've been kind of put out about. Maybe because
> of being only a sometimes coder or maybe because I arrived at perl
> from shell scripting and at one time a sort of heavey (not necessarily
> skilled) awk user.
>
> It seems perl coders like to jumble lots of actions into one line.
> And think of that as a better way.
>
> I don't doubt it is... and certainly not advocating against advice
> from a skilled and experienced user, but can you tell me how it is
> better? Is it faster for the interpreter to read or something else?
>
> To me its much harder to read later... mnths later when the script
> does something unexpected.. when used in a different way I hadn't
> tested it in.
>
> to me:
> my $var;
> if ($ARGV[0]){
> $var = shift;
> }
> if (!$var){
> $var = "someDefaultfile";
> }
>
> It is a good bit more drawn out but it tells me more about intent at a
> glance than what you used.
>
> If my kind of extra baloney is slowing down the excecution when
> taken as a whole .... that is many times more baloney when seen over
> 300 lines or so than the shorter ways like you posted, then its
> probably time for me to give up the long hand and start trying to go
> the shorter more concise route.
>
> Can you expound on that a bit?
snip
Perl is a language like English. There are certain idioms that are
well known and aid in understanding. The use of the or operator to
make defaults is one of these idioms. I don't find a bunch of if
statements to be particularly clear (especially when they use !, which
is small and hard to see when scanning code).
snip
> Can you show an example of how that new `//' operator works? I've got
> that version built and installed in a test area and all set to be
> shocked and amazed at new features... : )
snip
It is used just like the || operator, but instead of checking for
truth, it checks for definedness. So you can say things like
sub wait_for_it {
my $wait = shift // 10;
sleep $wait;
}
instead of
sub wait_for_it {
my $wait = shift;
$wait = 10 unless defined $wait;
sleep $wait;
}
You can find information about the new features here:
http://search.cpan.org/~rgarcia/perl-5.10.0-RC2/pod/perl5100delta.pod
The things I am looking forward to
* the say function (like print, but appends a "\n")
* the defined-or operator (//)
* the given/when flow control operator (think very powerful case statements)
* the smart match operator (very powerful)
* Named Capture Buffers and the new variables %+ and %- (easier to
read than $1, $2, $3)
* Stacked filetest operators (you can say -f -x $file instead of -f
$file && -x $file)
* unpack and mkdir now default to using $_ if no arguments are supplied
* the less pragma actually does something now
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
