Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re: Slurp

by rob_au (Abbot)
on Dec 30, 2002 at 22:53 UTC ( [id://223209]=note: print w/replies, xml ) Need Help??


in reply to Slurp

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

Replies are listed 'Best First'.
Re: Re: Slurp
by chromatic (Archbishop) on Dec 31, 2002 at 00:18 UTC
    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"))'

Re^2: Slurp
by Aristotle (Chancellor) on Jan 04, 2003 at 14:25 UTC

    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: Re: Slurp
by Juerd (Abbot) on Dec 31, 2002 at 15:48 UTC

    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.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2024-03-28 17:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found