|laziness, impatience, and hubris|
Re: Slurpby rob_au (Abbot)
|on Dec 30, 2002 at 22:53 UTC||Need Help??|
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 ...
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:
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.
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.
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.
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".
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"))'