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

Re: Question/suggestion on perlfunc.pod example

Thread Previous | Thread Next
Aristotle Pagaltzis
May 13, 2015 00:51
Re: Question/suggestion on perlfunc.pod example
Message ID:
* Glenn Golden <> [2015-05-13 00:35]:
> How about including the return value test in the example simply as
> a comment-only clause, just for pedagogical purposes, since it is
> explicitly discussed just prior in the text. So perhaps just
> augmenting your version like this or so:
>     {
>         local ($!, $@);
>         my $result = do $file;
>         if ($@)
>             { warn "Couldn't run $file: $@" }
>         elsif ($! and not defined $result)
>             { warn "Couldn't load $file: $!" }
> 	      else
>             { # Here if final statement of $file evaluates to 'false' }
>     }

Uh. That addition is completely bogus. That else-branch is reached when
a) $@ is false and b) $! is false or $result is defined or both. So that
branch may well be reached when $result is true, and will *usually* be
reached without the truthiness of $result having been tested at all. So
that comment is a falsehood.

Now you could fix that by making the `else` into `elsif (not $result)`.

But why would anyone write the code that way?

First of all, the only value of $result that even possibly has universal
meaning is undef – that is the only value sometimes returned by perl.
Any other value depends on the return value protocol you expect the code
in $file to follow – if any.

Second, in light of that:

> The reason I like this is simply because then the example includes all
> the eventualities, which is just what I (as a non-expert Joe User) was
> looking for when reading up on 'do' and came across this. I understand
> your point that the test doesn't have much practical value outside of
> a particular usage context such as reading a config file, but it's
> nevertheless useful to folks like myself just to see it explicitly
> called out, as an illustration of the semantics of the return value.

Think about what happens in the code that comes right after the example.
If you didn’t `do $file` purely for side-effects, but to get a $result
value, then no matter what code you write next, it will inevitably be
doing something with or to $result. And if you did `do $file` purely for
side-effects, then you shouldn’t care about its return value beyond the
weak/buggy attempt to verify the $! truthiness.

That is why I think that check does not belong in the example code. Even
if it is not shown, and even if you never stop to think about subtleties
of using `do`, you cannot fail to look at $result if it matters, and you
ought not to if it doesn’t.

Aristotle Pagaltzis // <>

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