I'm still not convinced. Your argument here appears to be "this is appropriate as a module because a beginning programmer would not be saavy enough to write this module."

The justification which I see for this module is not that a beginning programmer could not write this module, but rather to provide a very simple interface for reading files for that programmer.

I see merit in the Slurp module in that a beginning programmer can read one or more files into memory with a simple and direct one line construct such as:

@content = slurp("file1", "file2", ...);

While it is entirely true that this one line could be easily written as:

@content = do{ local( $/, @ARGV ) = ( undef, "file1", "file2", ...); <> };

Thereby alleviating the need for any additional module, I propose that it is relatively unlikely that a beginning programmer would be comfortable with such a construct - It is thus that I see merit in the Slurp module.

I'm also not convinced a beginning programmer would know enough to care about the difference between a function or a static method call. To your credit, the synopsis doesn't expose this, so you've ameliorated that somewhat.

It is for this very reason, the level of knowledge which may be assumed, that some attempt has been made to permit both function and static method calls to be made without error - This is an attempt to follow the "principle of least surprise" with regard to function reference.

The greater issue, which you rightly highlight, is the accessibility of this module to its target audience, in that it does assume knowledge of the existence of CPAN and module installation - This is a concern and perhaps the greatest problem with any module targeted at a beginning audience.

perl -le 'print+unpack("N",pack("B32","00000000000000000000001000001100"))'