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

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>

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]