develooper Front page | perl.perl5.porters | Postings from May 2015

Re: Question/suggestion on perlfunc.pod example

Thread Previous | Thread Next
Aristotle Pagaltzis
May 11, 2015 22:22
Re: Question/suggestion on perlfunc.pod example
Message ID:
* Glenn Golden <> [2015-05-11 23:25]:
> Regarding this example from perlfunc.pod, pertaining to "do":
>     ===================================================================
>     for $file ("/share/prog/defaults.rc", "$ENV{HOME}/.someprogrc")
>     {
>         unless ($return = do $file) {
>             warn "couldn't parse $file: $@" if $@;
>             warn "couldn't do $file: $!"    unless defined $return;
>             warn "couldn't run $file"       unless $return;
>         }
>     }
>     ===================================================================

Wow, that’s bad.

> Is the final "unless $return" necessary?


> Also: The meaning of the word 'run' in the warning text "couldn't run
> $file" seems unclear. If my understanding of the accompanying doc text
> is correct, seems like it should be possible to reach that warning
> clause only if the final expression resulting from evaluating $file is
> false. If this reading is correct, would it make sense to change the
> warning text to something more directly interpretable by the reader,
> e.g. "final expression evaluating $file is false"?

As far as the example goes, that would work. The apparent intent might
be better expressed by "invalid configuration returned from $file".

But the example doesn’t make much sense. You can write a “configuration”
file whose final expression yields undef and confuse it; as well, under
several conditions it will display several warnings for the same file.

I *think* this untested code covers all the bases…

    for my $file ("/share/prog/defaults.rc", "$ENV{HOME}/.someprogrc") {
        local ($!, $@);
        $return = do $file or warn
            ( $@                     ? "couldn't parse $file: $@"
            : $! && !defined $return ? "couldn't do $file: $!"
            :                          "invalid configuration returned from $file"

… but I’m not sure about $! and there may not be any unambiguous signal
for that case available.

Also, $@ being set doesn’t point to a parsing error specifically – just
an exception thrown at any point before the code in the file returned.
So that message is wrong.

In short… that is one terrible example.

> If so, I'll be happy to submit a doc patch for either/both of these
> changes, but wanted to first ask if my understanding of this was even
> correct.

It doesn’t make sense to me to promote `do` as a configuration loader
mechanism in the first place, not even in trying to contrive a use case
for `do`. I’d go with a narrowly focused example, dumping the loop and
rewording the error messages to purely problem-domain statements that
describe each error condition precisely.

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About