Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re: Re: Slurp

by Juerd (Abbot)
on Dec 31, 2002 at 15:48 UTC ( #223348=note: print w/replies, xml ) Need Help??

in reply to Re: Slurp
in thread Slurp

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's self_or_default method

But 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]. provides a functional syntax for something that is object oriented. This is acceptable (I still don't like it). 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 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?

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

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2021-12-08 23:06 GMT
Find Nodes?
    Voting Booth?
    R or B?

    Results (36 votes). Check out past polls.