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

Re: Question/suggestion on perlfunc.pod example

Thread Previous | Thread Next
From:
Aristotle Pagaltzis
Date:
May 11, 2015 22:22
Subject:
Re: Question/suggestion on perlfunc.pod example
Message ID:
20150511222148.GA1321@plasmasturm.org
* Glenn Golden <gdg@zplane.com> [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?

No.

> 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.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About