Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: (dmm): Time to seconds

by dmmiller2k (Chaplain)
on Nov 16, 2001 at 02:43 UTC ( #125706=note: print w/ replies, xml ) Need Help??


in reply to Re: Time to seconds
in thread Time to seconds

Bravo! (Just what I was thinking).

However, as an alternative to using no warnings 'uninitialized' (always appear as though you thought of everything), try OR-ing the hash values with 0, like this:

my %time=reverse split(/([HMS])/, '5H3M17S'); my $time = (( (($time{H}||0) * 60) + ($time{M}||0)) * 60) + ($time{S}| +|0);

dmm


Comment on Re: (dmm): Time to seconds
Select or Download Code
no warnings 'uninitialized' (was:Time to seconds)
by blakem (Monsignor) on Nov 16, 2001 at 07:03 UTC
    I have to disagree. I think no warnings 'uninitialized' is a much more elegant way to avoid those idiotic warnings. For one thing, they shouldn't be warnings in the *first* place. In this example, the expression that triggers the warning is:
    60 * undef
    Why should this cause a warning? The behavior is well-defined, documented, rational, and well understood. I don't think perl should be warning me about this since it is a feature of Perl!

    Your solution (nothing personal, its a common workaround) converts the above expression to:

    60 * (undef || 0)
    Which doesn't spew out a warning... The question is why not? If the first one gives me a "Use of uninitialized value in multiplication" error, why wouldn't this give me a "Use of uninitialized value in logical OR" error? Its not like undef in boolean context is more well-behaved than in numeric context1. Why should one throw a warning and the other not... Either both should trigger warnings and we sprinkle lots of defined() calls everywhere, or neither should.

    Adding gratuitous logic to avoid spurious warnings doesn't agree with me. Better just to turn those specific warnings off and be done with it.

    1I know thats splitting hairs, but the fact that it is splitting hairs is kind of my point anyway.

    -Blake

      Why should this cause a warning? The behavior is well-defined, documented, rational, and well understood. I don't think perl should be warning me about this since it is a feature of Perl!

      Because using undef in a math operation is generally a Weird Thing, and by turning on warnings you've asked Perl to warn you about Weird Things.

      If the first one gives me a "Use of uninitialized value in multiplication" error, why wouldn't this give me a "Use of uninitialized value in logical OR" error?

      The reason is that logical or is often used as a defaulting operator. That idiom--$foo||$default--is so common that it's getting its own syntax in Perl 6--the new // defaulting operator, which only returns the right operand if the left operand is undefined. With this addition to Perl 6 perhaps the warning you mention will appear.

      PS Sorry if this has the tone of lashing out angrily at you or something. It's probably too late for me to be safely posting to the Monastery anyway... :^)

      =cut
      --Brent Dax
      There is no sig.

        It's not weird its perlish.TM ;-)
        But seriously, using "uninitialized" variables is done all the time in perl. The weird part is trying to figure out when doing so will trigger a warning and when it won't. I'll be very impressed if you can tell what warnings the following code will produce:
        #!/usr/bin/perl -T use warnings; use strict; my ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m); $a++; $b += 1; $c = $c + 1; $d->{size} = 'big'; $e->[5] = 35; $_ .= "$f"; $_ .= $g; $_ = 'h=' . $h; $_ = $i . '=i'; $_ = "j=$j"; $_ = "$k=k"; $_ = $l x 5; $_ = "$m" x 5;

        ANS: $c,$f,$g,$h,$j, and $m are used it ways that trigger warnings $a++; # this is ok $b += 1; # this is ok $c = $c + 1; # but this is bad??? $d->{size} = 'big'; # both are just fine... treating undef as a hash + ref $e->[5] = 35; # is ok, but treat it like a 0 and I get yelled +at? $_ .= "$f"; # bad $_ .= $g; # still bad $_ = 'h=' . $h; # bad.... ok so you can't treat undef like a string $_ = $i . '=i'; # wait, no warning, maybe you can $_ = "j=$j"; # nope this tosses an error $_ = "$k=k"; # but this doesn't.... huh? $_ = $l x 5; # neither does this $_ = "$m" x 5; # but if I do the stringifing myself I get yelled at

        So, how did you do? I contend that you would have scored better on this quiz if I had asked about the values of the expressions rather than about the warnnings they may or may not trigger.

        Learning how undef behaves is easy... learning when it tosses warnings is hard. This can lead to gratuitious special-casing (i.e. if ($x && $x > 3) {$y = ($z||0) + 5)) whose sole purpose is to explicitly state that undef should be treated like, well, undef!

        -Blake

Re: Re: (dmm): Time to seconds
by BrentDax (Hermit) on Nov 16, 2001 at 13:02 UTC
    I would do that on a system without warnings; however, it's always a good thing to be explicit about such things. use warnings 'uninitialized' makes my intent--ducking the 'Use of uninitialized value in multiplication' warnings--more clear than sticking a bunch of default values in. Besides, it's easier to type than "shift-backslash-backslash-unshift-zero" x 3. :^)

    =cut
    --Brent Dax
    There is no sig.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://125706]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (13)
As of 2014-08-29 14:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (280 votes), past polls