Re^4: Why do we need a \n with do FILENAME?

examination of the code sample from do shows usage expects a defined test on the return value, likely for this very reason.

Actually the sample does not check on define, but on truth (which might have led ikegami into thinking that the file should always return true), but I believe that for this very reason this is just an example of how do might be used - otherwise the example would have explicitly say unless (defined($return = do $file)) to make it explicit that an undef return value does not make sense. Indeed, for reading a configuration file (which is what the example is about), it makes sense to require that the config file should return true in success; but I don't think this can be taken to mean that this always should be the case.

--
Ronald Fischer <ynnor@mm.st>

Comment on Re^4: Why do we need a \n with do FILENAME? Select or Download Code

Replies are listed 'Best First'.
Re^5: Why do we need a \n with do FILENAME? by kennethk (Abbot) on Jul 07, 2010 at 14:32 UTC
Actually the sample does not check on define, but on truth For the `$!` case, do says `warn "couldn't do $file: $!" unless defined $return;` The truth case is checking the success of the contained code, not the OS's ability to locate and execute file. I personally would go code diving before weighing in on the appropriateness of perl's behavior.	[reply] [d/l] [select]
Re^5: Why do we need a \n with do FILENAME? by ikegami (Patriarch) on Jul 07, 2010 at 16:24 UTC
which might have led ikegami into thinking that the file should always return true You could require your included file to return something defined. Requiring the included file to return something true is much clearer and simpler, though, and Perl programmers are already accustomed to doing that.	[reply]
Re^6: Why do we need a \n with do FILENAME? by rovf (Priest) on Jul 08, 2010 at 07:58 UTC
I would agree with you if the only purpose of `do` would be to "load subroutines and initialization code at runtime" in a similar way as `require` does, but for those (rare?) cases this should be done repeatedly. However, from my understanding of do, this function is much more general: It is, in spirit, much more like `eval`, only that the evaluated code resides in a file, not in a string or block. This can, IMO, not only seen from the description of `do`, but also from the fact that `$@` is set after an exception. We wouldn't place the requirment, that code evaluated by `eval` should return a true value unless it fails, do we? I, personally, would say that the same applies to `do`. Maybe our different views in that matters come from the fact that I'm using `do` in a different way. We are using it to inject (for purpose of debugging) arbitrary code at specific "hook point" in a running application. -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l] [select]
Re^7: Why do we need a \n with do FILENAME? by ikegami (Patriarch) on Jul 08, 2010 at 17:06 UTC
It is, in spirit, much more like eval, only that the evaluated code resides in a file, not in a string or block The reason for requiring for avoiding undef has nothing to do with the purpose of function, so this doesn't matter. We wouldn't place the requirment, that code evaluated by eval should return a true value unless it fails, do we? What does matter is the interface provided by the functions. `eval` has a different interface, so it really doesn't matter what you do with `eval`. However, it is indeed quite common to have `eval`'s body return true. `my $foo = eval ... or die("...: $@");` [download]	[reply] [d/l] [select]