Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Slurp

by Juerd (Abbot)
on Dec 30, 2002 at 17:55 UTC ( #223106=modulereview: print w/ replies, xml ) Need Help??

Item Description: Slurp entire files into variables

Review Synopsis:

During my daily http://search.cpan.org/recent ritual, I came across a new module called Slurp.

Slurp provides three functions: slurp, to_array and to_scalar. slurp is exported by default, the other two can be exported too.

Object orientation

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.

Naming

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

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.

Documentation

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

Conclusion

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.

I think it should be removed from CPAN, or at least be renamed to something in File::.

Comment on Slurp
Re: Slurp
by mojotoad (Monsignor) on Dec 30, 2002 at 18:23 UTC
    Next week, on Module Assassin...

    ;)

    I have to say I am surprised this one made it into the top level namespace. I don't mind having alternate solutions cropping up in CPAN, however.

    Matt

      I have to say I am surprised this one made it into the top level namespace.

      Then you misunderstand how CPAN works. Once an author has a PAUSE id, she can upload whatever modules she wants. It's only entry into the module list that you need approval for - and I'm guessing that Slurp hasn't yet made it into there.

      --
      <http://www.dave.org.uk>

      "The first rule of Perl club is you do not talk about Perl club."
      -- Chip Salzenberg

        As it is, I have not as yet applied for entry into the module list for some of the very issues raised in this review - Indeed, I will probably wait until I have had further feedback on the merit of this module before I am so audacious :-)

         

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

        No misunderstanding. I know there's nothing technically preventing someone from claiming a top-level namespace -- I was just surprised that it didn't cause a furor on the modules mailing alias, followed by subsequent requests to the author to consider renaming.

        Having said that, I must admit I have not been tracking the modules discussion content lately. Perhaps I'm not the only one.

        (on further reflection, perhaps my misunderstanding, if any, pertains to the level of attention paid to unregistered name spaces by the maintainers)

        Matt

Re: Slurp
by RhetTbull (Curate) on Dec 30, 2002 at 18:24 UTC
    Did you notify the author? I agree that a pet peeve of mine is modules with a single name. Me thinks that only a select few should have the power to upload top-level namespaces to CPAN. Perhaps the author wasn't aware of File::Slurp? If this module has anything better than File::Slurp perhaps the author would be willing to submit a patch. Although module reviews on perlmonks is a fine place for this I'd definitely start by notifying the author!

      Did you notify the author?

      Of course I did :)

      I wrote him this e-mail, a minute or so after posting the review here:

      Date: Mon, 30 Dec 2002 18:58:42 +0100 + Subject: Review of Slurp 0.02 + + http://perlmonks.org/index.pl?node_id=223106 + + If you want to comment on it, please do so on the PerlMonks website + instead of by e-mail. + + + Juerd +

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

Re: Slurp
by Anonymous Monk on Dec 30, 2002 at 18:33 UTC
    Juerd, why stop there? Why not take all the modules that you don't like and flame each author in turn. You could probably do, say, one a day. Which author are you planning to flame in tomorrow's post?

      Juerd, why stop there?

      Don't worry, I'll write some more :)

      Why not take all the modules that you don't like and flame each author in turn.

      Good idea, but that would be a lot of work. Please note that I did not flame in this review.

      You could probably do, say, one a day.

      No, I've got other things to do as well, you know.

      Which author are you planning to flame in tomorrow's post?

      I'm reviewing modules, not authors. Handy::Dandy was so full of (censored), that I couldn't refrain myself from flaming the author personally. I regret my actions and am moving on; I hope you will too. I don't know which module will be next. The author of Attribute::Default asked me to review that module, so you can expect a review soon. It's a rather large module, and I need to study on attributes before I *can* review it, so it might take some time.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

        Handy::Dandy was so full of (censored), that I couldn't refrain myself from flaming the author personally.

        Says a lot about you.

        "Follow me" said the blind man to the deaf one.

Re: Slurp
by chromatic (Archbishop) on Dec 30, 2002 at 20:54 UTC

    I question the need for a module that encapsulates a one-liner -- especially for a task as simple as this. That said, I do appreciate the @ARGV hack. That's pretty clever, even if it does pose error-handling problems.

      That said, I do appreciate the @ARGV hack. That's pretty clever, even if it does pose error-handling problems.

      I too appreciate the @ARGV hack. It handler errors by die()ing with a useful message. See also 204874 for lots of discussion about it.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

Re: Slurp
by rob_au (Abbot) on Dec 30, 2002 at 22:53 UTC
    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"))'

      The issue however has to do with the level of knowledge this assumes on the part of the programmer.

      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."

      I don't think that's a good criterion. A beginning programmer wouldn't necessarily know about localizing $/ for sure, nor about wantarray, but would said programmer attempt to write something abstract enough to handle both cases?

      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.

      Another consideration is that to use your code, a beginning coder would have to know about the existence of the CPAN, look for something named "slurp", install the module, and realize that error messages coming from your module are the fault of their code (if the file cannot be read).

      I find it more likely that a beginning Perl programmer would be able to write the appropriate code before he figures out how to install your module.

        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"))'

      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"

      Being fault tolerant is a bad way to teach newcomers.

      When I was learning about packages and objects, at first I thought :: and -> were the same thing. After all, with many modules both worked. Curse those modules! Without them, it would not have taken me so long to comprehend the material.

      In time, I used more and more modules. I liked -> because it was prettier. But some modules did not work with it. And others would not work with ::. If from the beginning there had been some indication abouth these two being different, I would have understood the difference much earlier.

      We advise newbies to use strict and warnings. These pragmata decrease fault tolerancy. They make the beginner think about what he does.

      Your way of helping is not helping at all. Thank you for trying, but you're only making things harder. If you want to help Perl initiates understand Perl, document that -> does not work, and explain why. If you really want to be fault tolerant, then do not document -> at all. I don't believe fault tolerancy really was your motivation: you would have used :: in the synopsis. Slurp's documentation actually promotes the use of -> where :: is much more appropriate. Please consider another way of helping.

      The code for this "fake object orientation" is taken from the CGI.pm's self_or_default method

      But CGI.pm really is object oriented. It provides a functional interface, where a object is automatically initialized. self_or_default always returns a CGI object, you only decide whether or not you're going to use $_[0].

      CGI.pm provides a functional syntax for something that is object oriented. This is acceptable (I still don't like it).
      Slurp.pm provides an object oriented syntax for something that doesn't use objects. There's no object. Not even a package global (or file scoped lexical) in which some data is stored. There is no object orientation, only its syntax.

      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.

      Er, ehm. Right. Well. Er? Humm??

      And why would anyone use Slurp instead of File::Slurp? And *if* there's anything that Slurp has that File::Slurp has not, wouldn't it be a good idea to patch File::Slurp?

      rather a simple and direct interface for slurping files into variables.

      That is exactly what File::Slurp provides. Together with that, it happens to provide functions that write files. Your module's functionality *completely* overlaps File::Slurp's.

      I would also note that I did also put some effort into the short tests for this module

      I haven't installed or tried Slurp.pm. Its source only reached my computer through the browser. That's why I didn't comment on your tests. Having tests is a good thing - I hope one day I too will know how to write good tests (for existing modules -- can anyone help me write tests for DBIx::Simple for example? I have no idea where to start. My only module with tests is Crypt::Caesar, but that was trivial.)

      Simply because another module provides similar functionality does not negate the worth of additional similar modules

      You are right. Having alternatives is a good thing. But not when two alternatives are EQUAL. You might not have noticed, but you reinvented exactly the same wheel that File::Slurp already provides. With only syntactical differences (your module tolerates false OO, and a list of files can be used instead of just one - nothing worth a new module, in my opinion).

      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.

      You're now asking newbies to choose between two equivalent modules. Equivalent in slurping functionality, equivalent in quality. That's *hard*, especially if you don't have enough knowledge to base a decision on.

      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 assume things. But both monks and the module authors can tell me I'm wrong if I am. That's why I send e-mail, that's why I post the reviews on PerlMonks. There's even the opportunity for anonymous lamers to flame without getting their own accounts downvoted.

      however from a functionality standpoint, I believe that this module still has merit and an audience which could benefit from its use.

      It would have been a great module if we didn't have File::Slurp already. Really, both your code and documentation are well written. But it doesn't add anything new to CPAN. Please at least think of a name that starts with File::. Maybe File::Slurp::Alternative, or File::OtherSlurp or something like that.

      I thought about this for a while.

      There are definitely good reasons for beginners to be exposed the idiom in question and all of its facets. It is a noble idea to do something to increase awareness with whichever approach seems appropriate. However, I believe writing a module is ineffective in this case.

      A beginner will benefit greatly for reading and understanding all the various details which comprise this idiom. However, that implies reading the code you used, not dropping a blackbox tnto one's code.

      For the latter purpose, File::Slurp fits the bill perfectly.

      For the former purpose, a detailed tutorial that explains the nooks and crannies seems to be the way to go. I don't think making it available as a module will achieve any increase in awareness - beginners more so than anyone else tend to not even take a cursory look into the guts of modules.

      Note also that as discussed in the node Juerd referenced, the snippet as is is broken. And understanding why that is, actually, will benefit a beginner even more. There are dozens of lessons to be had in this snippet. But one has to read it and have it explained to learn them.

      Makeshifts last the longest.

Re: Slurp
by boo_radley (Parson) on Dec 31, 2002 at 00:03 UTC
Re: Slurp
by Anonymous Monk on Dec 31, 2002 at 08:27 UTC
    The author clearly didn't search CPAN, or wants to compete.

    Since when is competition a bad thing? The more choices available the better. Let people choose which module they want. Should Burger King be eliminate because it "duplicates the functionality" of McDonalds? Maybe Open Office should be shutdown because it duplicates MS Word's functionality and we wouldn't want to confuse people, would we?

Back to Reviews

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: modulereview [id://223106]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (3)
As of 2014-07-14 01:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (253 votes), past polls