Most useful standard module?

[Davy]

Hi all,

I have used Getopt::Std and File::Find. I found standard module useful.

Is there any artical summarize the most useful standard module?

Best regards,
Davy

 

[Paul Lalli]

I have used Getopt::Std and File::Find. I found standard module useful.

Is there any artical summarize the most useful standard module?

Your question is somewhat nonsensical. The most useful module is
dependent on what your program is trying to accomplish. List::Util
might be terribly useful in one script, but completely unnecessary in
another.

The two modules (really, pragmas) that you should have in EVERY script
are strict and warnings.

Paul Lalli

 

[Klaus]

I have used Getopt::Std and File::Find. I found standard module useful.

Is there any artical summarize the most useful standard module?

The answer to this question depends very much on personal style and
preferences.

There is an article about modules by Damian Conway at
http://www.oreilly.com/pub/wlg/7507

Those modules look "most useful" to me (although I don't know if they
are "standard" yet)

There is also a podcast from OSCON 2005 where Damian himself presented
his modules:

2005-09-10: This is a recording of Damian Conway presenting the Conway
Channel 2005 at O'Reilly's Open Source Convention in Portland Oregon.
at http://www.perlcast.com/episodes

direct link to podcast:
http://perlcast.com/audio/Perlcast_Presentation_001_Conway_Channel_OSCON_2005.mp3

 

[John Bokma]

Hi all,

I have used Getopt::Std and File::Find. I found standard module useful.

Is there any artical summarize the most useful standard module?

Not really, and as others have said, it depends on what you are doing, and
of course its a matter of taste.

Modules I use a lot are (unordered):

LWP::UserAgent;
HTML::TreeBuilder;
File::Slurp;
Storable;
Data:umper;

(I am just awake, so there might be typos).

 

[Jamie]

Hi all,

I have used Getopt::Std and File::Find. I found standard module useful.

Is there any artical summarize the most useful standard module?

Best regards,
Davy

I'd vote for:

#1 Data:umper

I also really like IO::File and IO::Handle I know there are many other ways to
work with file handles, but to me, the IO::* stuff seems to make more sense. If
you get in the habit of only using getline() and close(), you can easily create
your own objects that return text lines w/out having to mess with TIE. I find
this easier, but then, I tend to consider 'tie' to be a bit of a hack. Others
will disagree, which is fine.

It really is a matter of style:

I tend to think of 'strict' and 'warnings' as more programming
pragmas that happen to work with 'use'. But, since others are addressing
warnings and strict, I'll add my two bits.

Personally, I *really* like 'use strict'.

I do make use of the -w switch now and then when trying to diagnose something,
but I'm not to big on 'use warnings'. Data:umper is my friend and to me
anyway, far more useful when figuring out problems.

Granted, working in a group setting where the other members have proclaimed
though shalt use warnings and I'm quite open and comfortable with it. (Next time
I do something, I might check to see if 'use warnings' will warn me about objects
not being cleaned up at the end. THAT would be a useful warning.)

When I'm on my own, I just don't see the value of it when creative use of
Data:umper almost always finds problems without finding lots of non-problems.

Varies with case-to-case, standard disclaimers apply, don't jump down my throat
I do agree there are times when -w *is* useful. Saying anything to the
contrary of 'warnings' usually gets you arrested by the perlice...

Jamie

 

[Tad McClellan]

I do make use of the -w switch now and then when trying to diagnose something,
but I'm not to big on 'use warnings'.

"use warnings" is far superior to the -w switch.

Data:umper is my friend and to me
anyway, far more useful when figuring out problems.

Some people want a friend that helps them _discover_ problems too...

When I'm on my own, I just don't see the value of it

If you should, heaven forbid, ever have a "warnable" bug in your
program, then without warnings you silently get the wrong output
while with warnings you noisily get the wrong output.

I like to _know_ when I'm getting the wrong output. I suppose some
people would rather let the customer find it rather than a machine?

Data:umper almost always finds problems

Discovering bugs and diagnosing bugs are apples and oranges.

(D: is one of my favorite modules too, I've often wondered why
it is not mentioned in the "usual"[1] data structure pods.
)

without finding lots of non-problems.

Warnings don't often find non-problems in my code.

You must be doing something differently.

Varies with case-to-case, standard disclaimers apply, don't jump down my throat

I hope this followup sounds like countering your bad advice rather
than throat-jumping...

I do agree there are times when -w *is* useful.

("use warnings" is far superior to the -w switch.)


Then why not take advantage of its usefulness?

Do you _like_ finding the bugs yourself rather than having a
machine find them for you?

Saying anything to the
contrary of 'warnings' usually gets you arrested by the perlice...

warnings are like seat belts.

If you don't get in an accident, then you don't need them.

The Police are just trying to save you potential pain.

Thank them, and buckle up!



[1] perlreftut.pod perlref.pod perllol.pod perldsc.pod.

 

[fishfry]

"use warnings" is far superior to the -w switch.




Some people want a friend that helps them _discover_ problems too...

That's what endusers are for

 

[anno4000]

That's what endusers are for

Banana Software: Maturing after delivery.

Anno

 

[Chris Richmond - MD6-FDC ~]

"use warnings" is far superior to the -w switch.

("use warnings" is far superior to the -w switch.)

Tad,

You've been doign this forever (me too) and I respect your opinion,
but *why* is "use warnings;" better than -w on line #1? If its so
you can disable warnings in certain places then that defeats the
requirement to enforce non-warnable code.

Here's another question. Why are 'my' variables immune to some
of the -w checks ('used only once' for example)?

I've been using perl in a huge project for ~12 years and started
with perl4. perl5 introduced use strict; which forces 'my' (or global)
on everything and at the same time breaking pieces of warnings.
Long ago, we packaged all subroutines to pseudo hide variables
from being global by default, used -w, and this has been very
successful. Its all procedural code. No OOP whackiness.

Thx, Chris

 

[Dr.Ruud]

Chris Richmond - MD6-FDC ~ schreef:

*why* is "use warnings;" better than -w on line #1?

See warnings (which mentions perllexwarn).

 

[DJ Stunks]

Hi all,

I have used Getopt::Std and File::Find. I found standard module useful.

Is there any artical summarize the most useful standard module?

I vote for Miss Storable. She looked INCREDIBLE in that swimsuit =p~

-jp

 

[Tad McClellan]

but *why* is "use warnings;" better than -w on line #1?

Scoped warnings are better than global warnings for reasons similar
to why scoped variables are better than global variables.

If its so
you can disable warnings in certain places then that defeats the
requirement to enforce non-warnable code.

You can disable only the offending warning with the pragma:

{ no warnings 'uninitialized';

# no seat belts here
}

If you are forced to use a non-warnings-clean module, the -w spews
a bunch of stuff that you have no control over, which "trains" you
to ignore warnings even if there might be a "real" one in amongst
all of the noise.

 

[Chris Richmond - MD6-FDC ~]

If you are forced to use a non-warnings-clean module, the -w spews
a bunch of stuff that you have no control over, which "trains" you
to ignore warnings even if there might be a "real" one in amongst
all of the noise.

Oh, that sort of explains things. We treat warnings as fatal
errors. They *have* to be fixed or the code doesn't get released.

Thx, Chris

 

[Ben Morrow]

Quoth (e-mail address removed):

Oh, that sort of explains things. We treat warnings as fatal
errors. They *have* to be fixed or the code doesn't get released.

In that case you may be interested in the -W switch, which turns on all
warnings everywhere regardless of 'no warnings' or $^W. You should
probably read perllexwarn, as the new (well, since 5.6, which isn't
exactly new) architecture is worth working with rather than against.

Ben

 

[Dr.Ruud]

Chris Richmond - MD6-FDC ~ schreef:

We treat warnings as fatal
errors. They *have* to be fixed or the code doesn't get released.

Have you grepped all source for blocks with

local $^W

or

no warnings

in them? Or are those accepted fixes?

 

[Tad McClellan]

We treat warnings as fatal
errors.

So do I.

 

[Brian Greenfield]

On Fri, 25 Aug 2006 21:17:38 +0000 (UTC),

We treat warnings as fatal
errors. They *have* to be fixed or the code doesn't get released.

Another thing you can do with the warnings pragma that you can't with
perl -w (AFAIK) is

use warnings FATAL => 'all';

Now, you don't have any option to ignore warnings

 

[Paul Lalli]

Chris Richmond - MD6-FDC ~ schreef:


Have you grepped all source for blocks with

local $^W

or

no warnings

in them? Or are those accepted fixes?

No reason for the grep. Provide the -W option on the command line,
which overrides both 'no warnings' and $^W.

Paul Lalli

 

[Chris Richmond - MD6-FDC ~]

Chris Richmond - MD6-FDC ~ schreef:

Have you grepped all source for blocks with
local $^W or no warnings
in them? Or are those accepted fixes?

No and no. Its a community of developers that those sorts of
things would bring a lot of bad peer pressure & public humiliation.

 

[Chris Richmond - MD6-FDC ~]

Another thing you can do with the warnings pragma that you can't with
perl -w (AFAIK) is
use warnings FATAL => 'all';

We did something similar to that in the bootup code, but
it isn't "on" after bootup.