Firstly, I must say it was with some trepidation that I clicked on the link to read this module review of Slurp from Juerd following the review of Handy::Dandy posted last week. Following on from the thread that ensured and the scathing reception received by Tommy Butler to this site, I must say that it is quite admirable to observe the manner by which he received such criticism in good humour and is now seeking to build constructively on the advice given. That having been said, I must say that I was still unsure what to expect when I saw this module review posted in Newest Nodes.

On to the review ...

 

Again, fake object orientation. You can use either slurp($filename) or Slurp->slurp($filename) to do exactly the same thing. I fail to see how Slurp->to_array is any better than Slurp::to_array. Both can be used.

 

The question of object orientation is interesting - This module is quite obviously targeted at the beginner programmer, intended to provide a means of facilitating the simple import of data from files. With this in mind, I wanted to make the interface as simple and forgiving as possible, such that a beginner could issue either Slurp::to_array or Slurp->to_array without error, hence this "fake object orientation" - In this matter, intent on functionality, or more precisely, simplicity, was the driving factor in this syntax. The code for this "fake object orientation" is taken from the CGI.pm's self_or_default method (also taking note of the obversations posted by demerphq in this thread here), which, right or wrong in concept, does provide a robust interface for the module, well suited for beginner programmers. With this same intended audience, this module is not intended to form any true object-orientated interface, its purpose is much more simplistic and direct.

While I agree whole-heartedly with the sentiments of chromatic on the necessity of a module to encapsulate a one-liner, I feel we are talking about two separate groups in this instance - It is true that this code could be replaced in functionality within another application by a single line of code similar to the following:

[ $scalar | @array ] = do { local( $/, @ARGV ) = ( wantarray ? $/ : undef, @_ ); <> }

The issue however has to do with the level of knowledge this assumes on the part of the programmer. For a beginner programmer, it is more likely that they will resort to a foreach- or while-loop to read a file into a memory, rather than this simple hack. It is to this audience that the Slurp module is intended to be of use - To simplify code and provide a direct means of obtaining such functionality.

 

This module handles files, so it should be in the File:: namespace. It is, however, just called Slurp. A much better name would be File::Slurp. But that module already exists.

File::Slurp provides exactly the same functionality, plus some extra handy functions. It has been around since 1996 and is does its job well. Slurp has no advantage over File::Slurp. The author clearly didn't search CPAN, or wants to compete.

 

On one point, we do agree - A better name for this module would be File::Slurp but such a module does already exists. I did consider posting Slurp in the Acme:: namespace, but was unsure as to whether it fitted with the theme of existing modules in this namespace.

I would however object to the statement that I either failed to search CPAN or sought to compete with the existing File::Slurp module - I did review this module prior to writing and posting the Slurp module, following which I still felt that there was merit in the Slurp module. Indeed, upon review of the existing File::Slurp module, there were some aspects of this code which I felt warranted attention, but fell outside the scope of the intended focus for the Slurp module - I did not want to write another "(simple|portable) interface for manipulating files" (of which there are many on CPAN - this form of module and DBI wrappers do noteably comprise a large portion of the CPAN namespace), rather a simple and direct interface for slurping files into variables. Whether this is a valid argument may be questioned, but it was the motivation in this case.

I would also note that I did inform the maintainer of File::Slurp, David Muir Sharnoff (MUIR) of the upload of this module (immediately upon upload to CPAN) and the intended difference in focus - I have not as yet recieved a reply from David on this matter.

 

The only positive sound about this module you'll hear from me is: nice documentation! Every function is docmented in detail.

 

Thank you - Documentation is usually my weakest aspect in the development cycle.

I would also note that I did also put some effort into the short tests for this module - I believe that mandatory reading for all module maintainers are the excellent Introduction to Testing and Perl Testing Tutorial written by chromatic.

 

Slurp does what it is supposed to do and is documented quite well. However, it should not be on CPAN, for two reasons: it is not in the correct namespace and another module already provides the functionality. This module adds nothing to CPAN but needless confusion for people in search of a file slurping module.

 

On this point, I disagree. Simply because another module provides similar functionality does not negate the worth of additional similar modules - If this were true, modules such as CGI::* and *::Session may also too deserve to go through a cull process. It is true that the Slurp module has similar focus to the existing File::Slurp module - But its focus is much more narrow and differs by the method in which it implements its functionality, itself, I believe, an element of worth in a community obsessed with the concern of "there being more than one way to do it".

Furthermore, given that only two modules currently on CPAN incorporate the term "Slurp" in their name, File::Slurp and Slurp, the argument for confusion is weak.

 

In conclusion, I would like to thank you for your review of this module - This having been said however, I do not believe that the general approach of harsh reviews or assumptions being made as to the actions or motives of module authors serves the Perl community well. I do agree with you that there are general issues with regard to CPAN namespace and perhaps to the placement of this module in said namespace, however from a functionality standpoint, I believe that this module still has merit and an audience which could benefit from its use. The wider issues with regard to the CPAN namespace, the moderated review of modules and alike certainly warrant consideration, but do not feel that these module reviews serve as the best place for their consideration.

 

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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.