in reply to Re^2: setting up boolean parameters from keywords
in thread setting up boolean parameters from keywords

could I just intialize the hash with a full list of options set to false, then set them true based on $4?
my %control = map { $_ => 'false' } split ' ', 'play ctrl loop' my %control = map { $_ => 'true' } split ' ', $4;

Replies are listed 'Best First'.
Re^4: setting up boolean parameters from keywords
by ff (Hermit) on Mar 18, 2006 at 04:49 UTC
    my %control = map { $_ => 'false' } split ' ', 'play ctrl loop' my %control = map { $_ => 'true' } split ' ', $4;
    Nice logic, but you will clobber all those 'false' key/value pairs by assigning a new list to %control. Replace the second line with something like the following and you should be set:

    $control{$_} = 'true' foreach split ' ', $4;

    Some people feel the long form is more maintainable:

    foreach ( split ' ', $4 ) { $control{$_} = 'true'; }
      Thanks!
      Now that I see it longform it makes a more sense the other way.
      So is perl always so versatile in regards to parameter ordering? That is soooo slippery to put the foreach after the assignment, but it is readable.
        The 'perlintro' section of the documentation mentions this via the term 'post-condition'. Basically, control terms like while, if, foreach, unless can come after the execution portion, making the execution conditional. The "thing to do" doesn't have to be in a statement block (because you are setting up only ONE thing to do) and the conditional part after the control term doesn't need to be in parens. (Less clutter overall.) What else would you expect from a linguist who thought such contructs perfectly normal in speech and so why not in logic? So, you will see things like:

        next if /^#/; last if /#{5,}/; warn "B-Fruit: '$_'\n" foreach grep { /^b/ } @fruits; build_acty_for_callout_at_sub_loc_hash( $fxhr, $previous_data_ar, \%acty_for_callout_at_sub_loc ) unless %acty_for_callout_at_sub_loc;

        Personally, it annoys me to read a line of Perl and midway through the line, or almost at the end, find such a qualifier term. (All that thinking through of what is going to happen and then you read if SOME CRAZY CONDITION THAT PROBABLY WON'T HAPPEN;) So, my preference is to spread such statements over two lines, so that your eyes see early on the left side the critical pieces of the statement. Like so:

        warn "B-Fruit: '$_'\n" foreach grep { /^b/ } @fruits;

        This particular example is one I would usually avoid breaking over two lines! Generally, I have lines like this in my code for debugging purposes, and usually they are commented out except for times when I want the extra verbiage to stand out. For these special cases, I only have to comment out one line if I keep the construct to one line instead of two. :-)

        A drawback with 'post-conditions' is that once you decide you would like to do two things instead of one, you must invert the construct back to the normal view, i.e.

        foreach ( grep {/^b/} @fruits ) { print LOGFILE "Found B-Fruit '$_'\n; warn "B-Fruit: '$_'\n"; }

        So at the end of the day, I believe you will find it is one of Damian's "Perl Best Practices" to avoid use of this construct except for super simple statements like  last unless @words