Front page | perl.perl5.porters |
Postings from May 2015
* 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