Newbie Help with Hashes

[James Bonanno]

Hello;

I've written a basic program that will scan a directory, and then
build a basic tree and turn that into HTML. The program is using the
File::Find::Rule and HTML::Template modules. I am building a basic
"project manager/reporting" software. I've arranged all my projects on
my computer in this strucutre:

Projects
--- Project1
----------Visio
----------Word
----------Schematics
----------Verilog
--- Project2
----------Visio
----------Word
----------Schematics
----------Verilog

. . . and so on. What I really want to do is to be able to have
"irregular" numbers of subprojects under each project, and gracefully
handle them with my code. For example, if Project1 contained a
subdirectory "Excel" in addition to Visio,Word,Schematic, and Verilog,
I'd like the program to be able to handle that rather than having a
"fixed number" of subprojects. My code is shown below, where the my
%row hash is the problem. I want to be able to make proj1, proj2,
proj3 a "dynamic size". I'm a newbie at perl, please forgive my
approach if another is clearly more obvious. Any suggestions are
welcome.
Thanks,

James

use File::Find::Rule;
use HTML::Template;

$root = "C:/DATA_JAMES/Projects/";
@projects_to_display = &dirscan_root("$root");

# Build an array of project names
@projects = &dirscan("$root");

# Build a hash of multi-value keys associating
# each project with its various subprojects/subdirectories
foreach $dir ( @projects ) {
$HoA{$dir} = [dirscan_root($dir)];
}

my $template = HTML::Template->new(filename => 'Find_Dir.html');
my @loop; # the loop data will be put in here

# fill in the loop, sorted by directory name
foreach my $name (sort keys %HoA) {
# get the directory and three proejcts from HoA hash
my ($dir, $proj1, $proj2, $proj3) = @{$HoA{$name}};
# make a new row for each project - the keys are <TMPL_VAR> names
# and the values are subprojects
my %row = (
dir => $name,
proj1 => $proj1,
proj2 => $proj2,
proj3 => $proj3,
);

# put this row into the loop by reference
push(@loop, \%row);
}
$nowstring = localtime;
# call param to fill in the loop with the loop data by reference.
$template->param(project_loop => \@loop);
$template->param(path => $nowstring);
print "Content-Type: text/html\n\n";
# print the template
print $template->output;

# This function scans the given directory and returns
# every subdirectory
sub dirscan_root{
$dir_to_scan = shift(@_);
@tree=File::Find::Rule->directory->relative->maxdepth(1)->in
("$dir_to_scan");
shift(@tree);
return (@tree);
};

# This function scans the given directory and returns
# an array with subdirectories indicated with a full path
sub dirscan{
$dir_to_scan = shift(@_);
@tree=File::Find::Rule->directory->maxdepth(1)->in("$dir_to_scan");
shift(@tree);
return (@tree);
};

[mooseshoes]

<snip>

What I really want to do is to be able to have

> "irregular" numbers of subprojects under each project, and gracefully
> handle them with my code. For example, if Project1 contained a
> subdirectory "Excel" in addition to Visio,Word,Schematic, and Verilog,
> I'd like the program to be able to handle that rather than having a
> "fixed number" of subprojects. My code is shown below, where the my
> %row hash is the problem. I want to be able to make proj1, proj2,
> proj3 a "dynamic size". I'm a newbie at perl, please forgive my
> approach if another is clearly more obvious.

<<< It appears that you may be in need of data strucure with an extra
dimension. Consider using an HoAoA so you can have varying numbers of
items per project. The best way to think of this data structure is a "hash
whose value references an array which references a second array." That
should help you add and extract items from it. Be sure to check out
various helpful perldocs on data structures and references.

Moose

[James Bonanno]

mooseshoes <mooseshoes@gmx.net> wrote in message news:<Sg89b.185$vv3.15572138@newssvr14.news.prodig y.com>...

> <snip>
>
> What I really want to do is to be able to have

> > "irregular" numbers of subprojects under each project, and gracefully
> > handle them with my code. For example, if Project1 contained a
> > subdirectory "Excel" in addition to Visio,Word,Schematic, and Verilog,
> > I'd like the program to be able to handle that rather than having a
> > "fixed number" of subprojects. My code is shown below, where the my
> > %row hash is the problem. I want to be able to make proj1, proj2,
> > proj3 a "dynamic size". I'm a newbie at perl, please forgive my
> > approach if another is clearly more obvious.

>
> <<< It appears that you may be in need of data strucure with an extra
> dimension. Consider using an HoAoA so you can have varying numbers of
> items per project. The best way to think of this data structure is a "hash
> whose value references an array which references a second array." That
> should help you add and extract items from it. Be sure to check out
> various helpful perldocs on data structures and references.
>
> Moose

====> Thanks Moose. I will look at the problem using the HoAoA approach. Kind
Regards, James

[Tad McClellan]

James Bonanno <jamesb7us@yahoo.com> wrote:

> use File::Find::Rule;
> use HTML::Template;

You are missing these:

use strict;
use warnings;

> @projects_to_display = &dirscan_root("$root");

Three different mistakes all folded in to a single line of code.

Impressive! :-)

my @projects_to_display = dirscan_root($root);


Declare your variables (use strict will _require_ you to do so).

Don't use ampersand on function calls (see perlsub.pod for what
that form of function call does).

perldoc -q vars

What's wrong with always quoting "$vars"?


--
Tad McClellan SGML consulting
[email]tadmc@augustmail.com[/email] Perl programming
Fort Worth, Texas

[Purl Gurl]

Tad McClellan wrote:

> James Bonanno wrote:

> You are missing these:

> use strict;
> use warnings;

Those are development tools and should be used when needed.
Dogmatic inclusion in all scripts serves no purpose and is
bad advice. Learn about strict and warnings rather than
simply toss them in because someone told you to do so.

Like all "things" in programming, strict and warnings offer
advantages and disadvantages. For some circumstances, use of
either can create more problems than resolved, although both
are generally good development tools.

Use strict and use warnings when you need help developing
a Perl script or to help you find problems later. Use both
if you are a beginner, after learning what they do, and
do not do.

Remove strict and warnings in a final script version to
improve efficiency, and to avoid security pitfalls.

> > @projects_to_display = &dirscan_root("$root");

> Don't use ampersand on function calls (see perlsub.pod for what
> that form of function call does).

Use &Sub_Routine when this is a better programming choice.
Research and read about sub-routine calls using Perl rather
than blindly follow Cargo Cult dogma.

Calls to subroutines afford many different syntax, each affording
advantages and disadvantages. Learn how to use Perl effectively
rather than learn how to regurgitate Cargo Cult advice, while
knowing very little about that advice.

Don't be a parrot. Be a good experienced programmer. Doing
so benefits you and the Perl Community.

Dogmatic promulgation of Perl 5 Cargo Cult dictates, is a bad
programming practice and a reflection of a lack of Perl knowledge.


Purl Gurl
--
Kick Ass Perl Programs
[url]http://www.purlgurl.net/~callgirl/android/android.html[/url]

Served up at one point five megabits a second, right here from home.

[Purl Gurl]

Purl Gurl wrote:

> Tad McClellan wrote:

> > James Bonanno wrote:

(snipped)

> > You are missing these:

> > use strict;
> > use warnings;

> Those are development tools and should be used when needed.
> Dogmatic inclusion in all scripts serves no purpose and is
> bad advice. Learn about strict and warnings rather than
> simply toss them in because someone told you to do so.

"Not everything runs cleanly under -w or use strict.
...starting off examples with my($this, $that) isn't
going to make them more readable....

...individual warnings cannot be turned on or off....
...no lexical scoped warnings....

...warnings impose a small speed penalty on programs.
...use -w at least long enough that the results are
no longer suprising...Warnings should be turned off
for code that is released to the world."

- Joseph N. Hall, Effective Perl Programming
co-authored by Randal Schwartz


"Learn how to use Perl effectively."
- Kira


Purl Gurl
--
Perl Documentation, Perl FAQs
Apache Documentation, Apache FAQs
[url]http://www.purlgurl.net[/url]
Purl Gurl Net is served up from our home

[Purl Gurl]

Purl Gurl wrote:

> Tad McClellan wrote:

> > James Bonanno wrote:

(snipped)

> Kick Ass Perl Programs
> [url]http://www.purlgurl.net/~callgirl/android/android.html[/url]

Sorry, my mistake. Bad URL reference.

[url]http://www.purlgurl.net/~callgirl/android.html[/url]


Purl Gurl

[Purl Gurl]

Purl Gurl wrote:

> Tad McClellan wrote:

> > James Bonanno wrote:

(snipped)

> > You are missing these:

> > use strict;
> > use warnings;

> Remove strict and warnings in a final script version to
> improve efficiency, and to avoid security pitfalls.

C:\APACHE\USERS\TEST>perl test.pl
Global symbol "$password_file" requires explicit package name at test.pl line 5

Execution of test.pl aborted due to compilation errors.

C:\APACHE\USERS\TEST>perl test.pl
Name "main::password_file" used only once: possible typo at test.pl line 5.



Purl Gurl
--
Learn To Read, Write And Speak Choctaw
[url]http://www.purlgurl.net/~choctaw[/url]
Purl Gurl Net, A Rare At Home Server

[Iain Truskett]

* Purl Gurl <purlgurl@purlgurl.net>:

(quoted text by
- Joseph N. Hall, Effective Perl Programming
co-authored by Randal Schwartz
)

[...]

> "Not everything runs cleanly under -w or use strict.
> ...starting off examples with my($this, $that) isn't
> going to make them more readable....

The full quote:

Not everything runs cleanly under -w or use strict (see
Item 36). I advise all Perl programmers to make use of
both -w and use strict regularly. However, starting off
all the examples with my($this, $that) isn't going to
make them more readable, and it's readability that's
important here.

What he's saying here is that having all the appropriate
declarations and stuff in his examples in the book would be
counter productive.

> ...individual warnings cannot be turned on or off....
> ...no lexical scoped warnings....

Out of date. These were both introduced in 5.6.

> ...warnings impose a small speed penalty on programs.

Irrelevant in most cases. Remember that EPP was released in
1997. The speed of the average machine has improved
dramatically and any speed loss from warnings is superbly
paid off by you always getting them. See fatal warnings
below.

> ...use -w at least long enough that the results are
> no longer suprising...

The full quote:

I recommend that programmers new to the Perl language,
regardless of their experience in other languages, use
-w at least long enough that the results are no longer
surprising. You should also use -w in combination with
use strict when developing code for important
applications or for public distribution. Of course, if
you are an "all warnings, all the time" sort of
programmer, just turn it on and keep it on.

> Warnings should be turned off for code that is released
> to the world."

Which, in my opinion, is not good. That last sentence
(sloppy editing you've been doing, Purl Gurl) goes on to
say:

"[...] much as assert() tests shouldn't be compiled into
final versions of C programs."

For a view opposite to the one in EPP, see "The Pragmatic
Programmer" by Dave Thomas and Andy Hunt, page 123. The gist
is that it's better to have a program stop than to go on
blindly, potentially corrupting data.

And in 5.6, you can even do:

use warnings FATAL => 'all';

which makes all warnings into errors. Look! Automatic
assertions. Marvellous.

> "Learn how to use Perl effectively."
> - Kira

Please. Do. For a start, remember to think about what you
read, rather than blindly agree. Some of your other posts
decry Cargo Culting. I recommend you do the same -- Culting
is bad whether it's from books or from usenet.



cheers,
--
Iain. <http://eh.org/~koschei/>

[Tassilo v. Parseval]

Also sprach Purl Gurl:

> Tad McClellan wrote:

>> You are missing these:

>

>> use strict;
>> use warnings;

>
> Those are development tools and should be used when needed.
> Dogmatic inclusion in all scripts serves no purpose and is
> bad advice. Learn about strict and warnings rather than
> simply toss them in because someone told you to do so.
>
> Like all "things" in programming, strict and warnings offer
> advantages and disadvantages. For some circumstances, use of
> either can create more problems than resolved, although both
> are generally good development tools.
>
> Use strict and use warnings when you need help developing
> a Perl script or to help you find problems later. Use both
> if you are a beginner, after learning what they do, and
> do not do.
>
> Remove strict and warnings in a final script version to
> improve efficiency, and to avoid security pitfalls.

You wont improve the efficiency by removing warnings or strict by a
measurable degree. Two third of strictures happen at compile-time for
instance.

Warnings wont do harm either since the code to check for warnings is
executed regardless of whether you have warnings enabled or not (it has
to be like that, otherwise perl can't figure out whether to warn or
not).

So the only slow-down warnings infer is when emitted a message to
stderr. But you usually use warnings in order to wipe out these warnings
during the development stage so this slow-down shouldn't ever happen.

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus}) !JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

[Purl Gurl]

Tassilo v. Parseval wrote:

> Purl Gurl wrote:

> > Tad McClellan wrote:

(snipped)

> >> You are missing these:

> >> use strict;
> >> use warnings;

> > Remove strict and warnings in a final script version to
> > improve efficiency, and to avoid security pitfalls.

> You wont improve the efficiency by removing warnings or strict by a
> measurable degree. Two third of strictures happen at compile-time for
> instance.

This is untrue. Joseph Hall, in his book "Effective Perl Programming,"
which is co-authored by Randal Schwartz, verifies a loss of efficiency.
You read my direct quote of Joseph Hall.

Previously, you have read my periodic articles providing benchmark
results on this topic. My tests measure a two percent to six percent
increase in efficiency by removing strict and warnings. Actual increase
in efficiency is directly proportionate to script complexity, with
warnings exhibiting the greater effect on script efficiency.

Three well known experts disagree with you.


Purl Gurl
--
Size Does Matter
[url]http://www.purlgurl.net/~godzilla[/url]

[Tassilo v. Parseval]

Also sprach Purl Gurl:

> Tassilo v. Parseval wrote:

>> You wont improve the efficiency by removing warnings or strict by a
>> measurable degree. Two third of strictures happen at compile-time for
>> instance.

>
> This is untrue. Joseph Hall, in his book "Effective Perl Programming,"
> which is co-authored by Randal Schwartz, verifies a loss of efficiency.
> You read my direct quote of Joseph Hall.

Yes, I read it. Nonetheless I think the statement's wrong.

The person who comes up with this assertion should actually explain to
me how this can happen on the C source-level.

> Previously, you have read my periodic articles providing benchmark
> results on this topic. My tests measure a two percent to six percent
> increase in efficiency by removing strict and warnings. Actual increase
> in efficiency is directly proportionate to script complexity, with
> warnings exhibiting the greater effect on script efficiency.

I remember very well having made a benchmark myself (and posted here)
that exhibits the opposite of what you claim to have figured out. I
might add: I don't have real faith in your benchmarking-skills.

Search google-groups.

> Three well known experts disagree with you.

Joseph Hall and Randal L. Schwartz...I fail to spot the third one.

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus}) !JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

[Purl Gurl]

Iain Truskett wrote:

> Purl Gurl wrote:

(snipped)

> (quoted text by
> - Joseph N. Hall, Effective Perl Programming
> co-authored by Randal Schwartz

> > "Not everything runs cleanly under -w or use strict.
> > ...starting off examples with my($this, $that) isn't
> > going to make them more readable....

> The full quote:

> Not everything runs cleanly under -w or use strict (see
> Item 36). I advise all Perl programmers to make use of
> both -w and use strict regularly. However, starting off
> all the examples with my($this, $that) isn't going to
> make them more readable, and it's readability that's
> important here.

> What he's saying here is that having all the appropriate
> declarations and stuff in his examples in the book would be
> counter productive.

Same logic applies for code examples posted to this group.
More often than not, you boys use a lack of strict and warnings
in posted code examples, to legitimize flaming an author.

Otherwords, you are looking for an excuse to troll.

Additionally, you boys dogmatically preach all scripts should
* always * include strict and warnings. That is bad advice
especially in lieu of you boys not mentioning problems which
can about, by following your dogmatic dictates.

> > ...individual warnings cannot be turned on or off....
> > ...no lexical scoped warnings....

> Out of date. These were both introduced in 5.6.

My guess is Perl version 5.6.x is the most used version of Perl.
Perl version 5.8.x is not very popular and, a guess, often
removed after installation because it breaks scripts and because
it is so buggy.

It would be of interest to locate statistics on which version of
Perl is most often used by individuals and servers. I strongly
suspect, this would be Perl 5.6 or lower.

> > ...warnings impose a small speed penalty on programs.

> Irrelevant in most cases.

A two to six percent loss in script efficiency is not irrelevant.
This is an unacceptable amount of efficiency loss.

My presumption is you hold an opinion both Joseph Hall and
Randal Schwartz are wrong about this.

> > Warnings should be turned off for code that is released
> > to the world."

> Which, in my opinion, is not good.

Then you are writing insecure Perl scripts and advising others
to do the same. This is not wise.

I agree with both Joseph Hall and Randal Schwartz on this.


You are flaunting your ignorance which is poorly veiled by verbosity.


Purl Gurl
--
Perl FAQs, Perl Documentation
Apache FAQs, Apache Documentation
[url]http://www.purlgurl.net/[/url]

[Purl Gurl]

Tassilo v. Parseval wrote:

> Purl Gurl wrote:

> > Tassilo v. Parseval wrote:

(snipped)

> >> You wont improve the efficiency by removing warnings or strict by a
> >> measurable degree. Two third of strictures happen at compile-time for
> >> instance.

> > This is untrue. Joseph Hall, in his book "Effective Perl Programming,"
> > which is co-authored by Randal Schwartz, verifies a loss of efficiency.
> > You read my direct quote of Joseph Hall.

> Yes, I read it. Nonetheless I think the statement's wrong.

You are noted as being an effective thinker.

> I don't have real faith in your benchmarking-skills.

You are providing an excellent example of why you are not noted
for being an effective thinker.

My benchmark tests * always * include benchmark coding so others
can replicate and verify my results, as is expected with good
Scientific Method.

Your habit of flaunting your lack of effective thinking, is humorous.


Purl Gurl
--

[Purl Gurl]

Purl Gurl wrote:

> Tassilo v. Parseval wrote:

> > Purl Gurl wrote:

> > > Tassilo v. Parseval wrote:

(snipped)

> You are noted as being an effective thinker.

You are not noted....

> Your habit of flaunting your lack of effective thinking, is humorous.

Purl Gurl

[James Bonanno]

Purl Gurl <purlgurl@purlgurl.net> wrote in message news:<3F6748D6.5CD6F15E@purlgurl.net>...

> Purl Gurl wrote:
>

> > Tassilo v. Parseval wrote:

> > > Purl Gurl wrote:
> > > > Tassilo v. Parseval wrote:

>
> (snipped)
>

> > You are noted as being an effective thinker.

>
> You are not noted....
>

> > Your habit of flaunting your lack of effective thinking, is humorous.

>
>
> Purl Gurl

----> Purl Gurl; Thank you for your insights. Regards, James

[James Bonanno]

[email]tadmc@augustmail.com[/email] (Tad McClellan) wrote in message news:<slrnbmc909.1td.tadmc@magna.augustmail.com>.. .

> James Bonanno <jamesb7us@yahoo.com> wrote:
>

> > use File::Find::Rule;
> > use HTML::Template;

>
>
> You are missing these:
>
> use strict;
> use warnings;
>
>

> > @projects_to_display = &dirscan_root("$root");

>
>
> Three different mistakes all folded in to a single line of code.
>
> Impressive! :-)
>
> my @projects_to_display = dirscan_root($root);
>
>
> Declare your variables (use strict will _require_ you to do so).
>
> Don't use ampersand on function calls (see perlsub.pod for what
> that form of function call does).
>
> perldoc -q vars
>
> What's wrong with always quoting "$vars"?

Tad;

I recommend to you to seek a Master of Business Administration degree
with a concentration in marketing. In that course of learning, you
will discover more strategic marketing concepts for your consulting
business rather than flaming a rather straightforward question on a
discussion group.

James

[Uri Guttman]

>>>>> "JB" == James Bonanno <jamesb7us@yahoo.com> writes:

JB> news:<slrnbmc909.1td.tadmc@magna.augustmail.com>.. .

>> James Bonanno <jamesb7us@yahoo.com> wrote:
>>

>> > use File::Find::Rule; > use HTML::Template;

>> You are missing these:
>> use strict; use warnings;
>>

>> > @projects_to_display = &dirscan_root("$root");

>> Three different mistakes all folded in to a single line of code.
>>
>> Impressive! :-)
>>
>> my @projects_to_display = dirscan_root($root);
>>
>>
>> Declare your variables (use strict will _require_ you to do so).
>>
>> Don't use ampersand on function calls (see perlsub.pod for what
>> that form of function call does).
>>
>> perldoc -q vars
>>
>> What's wrong with always quoting "$vars"?

JB> Tad;

JB> I recommend to you to seek a Master of Business Administration
JB> degree with a concentration in marketing. In that course of
JB> learning, you will discover more strategic marketing concepts for
JB> your consulting business rather than flaming a rather
JB> straightforward question on a discussion group.

and you are a fool if you think that was flaming. tad pointed out some
very common newbie bugs and problems with your code. as you are also
under the spell of moronzilla, the local troll. she may have satisfied
your current perl need but wait until you disagree with her or get into
a problem space where she won't tread (which is most of perl itself, she
sticks to simple text stuff and no regexes or refs - baby perl in the
extreme).

so go along your merry perl life and realize that you are backing the
wrong side here. search google for the history of tad's posting and of
moronzilla's. if you can't see the difference, you belong to her and woe
is you.

and this is not a flame even though you will probably take it as such.

uri

--
Uri Guttman ------ [email]uri@stemsystems.com[/email] -------- [url]http://www.stemsystems.com[/url]
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- [url]http://jobs.perl.org[/url]
Damian Conway Class in Boston - Sept 2003 -- [url]http://www.stemsystems.com/class[/url]

[Iain Truskett]

* Purl Gurl <purlgurl@purlgurl.net>:

> Iain Truskett wrote:

> > Purl Gurl wrote:

> (snipped)

> > (quoted text by
> > - Joseph N. Hall, Effective Perl Programming
> > co-authored by Randal Schwartz

[...]

> > The full quote:

>

> > Not everything runs cleanly under -w or use strict (see
> > Item 36). I advise all Perl programmers to make use of
> > both -w and use strict regularly. However, starting off
> > all the examples with my($this, $that) isn't going to
> > make them more readable, and it's readability that's
> > important here.

>

> > What he's saying here is that having all the appropriate
> > declarations and stuff in his examples in the book would be
> > counter productive.

> Same logic applies for code examples posted to this group.
> More often than not, you boys use a lack of strict and warnings
> in posted code examples, to legitimize flaming an author.

"you boys".

Anyway. Often the problem in the code is clearly illustrated
by perl itself if the author enables strict and warnings.
Often the author was ignorant of strict and warnings and
should be enlightened. Often the only person who will regard
it as flaming is you.

As Mr Hall and Mr Schwartz write (though I've often wondered
about what it was that Mr Schwartz wrote as the book says
"with" rather than "and"):

I recommend that programmers new to the Perl language,
regardless of their experience in other languages, use
-w at least long enough that the results are no longer
surprising.

> Otherwords, you are looking for an excuse to troll.

Just as you do when you see people recommend strict and
warnings or any other good practice.

> Additionally, you boys dogmatically preach all scripts should
> * always * include strict and warnings. That is bad advice
> especially in lieu of you boys not mentioning problems which
> can about, by following your dogmatic dictates.

"you boys". "can about".

It's good advice. Perhaps the advice could be augmented to
point to the documentation for strict and warnings so any
problems are brought to the original poster's attention?

First stage: the programmer doesn't know about strict or
warnings and blithely programs away, periodically wondering
why his or her program doesn't work, sometimes spotting
misnamed variables or realizing that variables don't have
values at various places (among other things). Maybe they
wonder if that stuff can be found automatically? Maybe they
give up on Perl because they don't know that it can be?

Second stage: the programmer finds out about strict and
warnings. And they use it. They suddenly find they can find
stupid errors faster, sometimes they'll also see warnings
about their variables having values they shouldn't (or,
rather, not having values when they should). If they're
lucky, they discover "use warnings FATAL => 'all';".

Third stage: They understand what strict and warnings are
offering and know enough Perl to write code that may need
strict 'refs' disabled, or something like that. They know
when and when not to use features of the language.

In short:
1 - Ignorance
2 - Practising
3 - Understanding

It's a road they should undertake themselves.

[..]

> > Out of date. These were both introduced in 5.6.

> My guess is Perl version 5.6.x is the most used version of
> Perl.

Excellent. You're not disagreeing with what I say. In fact,
it's a statement that supports what I say. Superb.

> Perl version 5.8.x is not very popular and, a guess,
> often removed after installation because it breaks scripts
> and because it is so buggy.

Curious. Didn't break any of mine. Maybe I should stop
writing code that is strict and warning clean? That way I
might experience some of this pain.

> It would be of interest to locate statistics on which
> version of Perl is most often used by individuals and
> servers. I strongly suspect, this would be Perl 5.6 or
> lower.

I suspect the former will be 5.6 or later while the latter
will be 5.6 or earlier. That said, most servers have at
least 5.005_03 these days with 5.004 remaining only in
either places it isn't used or places where progress is
inhibited by lack of a good testing environment (I speak
from experience there).

As 5.6 is "the most used version", then we should certainly
mention the use of its features, such as the warnings pragma.

> > > ...warnings impose a small speed penalty on programs.

>

> > Irrelevant in most cases.

> A two to six percent loss in script efficiency is not
> irrelevant. This is an unacceptable amount of efficiency
> loss.

> My presumption is you hold an opinion both Joseph Hall and
> Randal Schwartz are wrong about this.

I think you forgot the word "that". Your presumption is
incorrect. From what the book you're quoting says:

Run-time warnings impose a small speed penalty on
programs.

The 2-6% figure is one you came up with, correct? Forgive me
for not trusting your skills at benchmarking.

2-6% loss _is_ irrelevant. If you disagree, perhaps you
should be writing in C rather than Perl? After all, the
difference there is far greater. Worry yourself more about
50% loss. Or even 15-20%. 2-6% is negligible and often
amortized by the recovery.

> > > Warnings should be turned off for code that is released
> > > to the world."

>

> > Which, in my opinion, is not good.

>
> Then you are writing insecure Perl scripts and advising others
> to do the same. This is not wise.

'insecure'. Please, go on. Particularly in the case of 5.6's
fatal warnings, I'm currently failing to see how having code
that will abort if it reaches an inconsistent state and also
forces the programmer to take more care with their data is
making a program 'insecure'. The opposite is more probable.

There's arguably a case for when your program is being run
on different versions of Perl and thus particular warnings
may appear or not. This is a feature though as it indicates
precisely where you should examine your code to ensure that
its behaviour is correct for that edition of Perl. Without
the warning, your program could be getting itself into knots
and quite probably doing something you'll regret when you
get the results.

Not good when you're dealing with important things.

> I agree with both Joseph Hall and Randal Schwartz on this.

Good for you. In other news: let's quote another book now:

"[5] You are using warnings, right? You can enable them
with either -w or use warnings;"

(look, he's humorously assuming you're using warnings)

"If you tried running this, Perl may have given you a
helpful diagnostic message as a warning. If you didn't
get the warning, perhaps you didn't have warnings turned
on, either with the -w switch or with the use warnings
pragma. Even if you don't usually use Perl's warnings,
you should enable them during debugging. (How long would
it take you to debug this without Perl's warnings to
help you? How long would it take to enable Perl's
warnings? 'Nuff said.)"

(both from "Learning Perl Objects, References and Modules"
--- Randal Schwartz.)

> You are flaunting your ignorance which is poorly veiled by
> verbosity.

Whereas yours is exceptionally poorly veiled by inarticulacy?
English is a wonderful language. Forgive me I indulge in the
pleasure of using it. I far prefer to clarify and refine my
meaning than to offer short, sharp statements that are likely
to be misconstrued due to perceptions and misperceptions of
the meanings of the words I choose.


cheers,
--
Iain.

[Helgi Briem]

On 16 Sep 2003 18:25:38 -0700, [email]jamesb7us@yahoo.com[/email] (James Bonanno)
wrote:

>I recommend to you to seek a Master of Business Administration degree
>with a concentration in marketing. In that course of learning, you
>will discover more strategic marketing concepts for your consulting
>business rather than flaming a rather straightforward question on a
>discussion group.

Tad McCellan is a genuine Perl expert. You would
be well advised to take his recommendations seriously.

If you consider his post "flaming" you haven't been
around Usenet very long. I can see no sign of flaming
in his post.

You would also be well advised to ignore any and
all recommendations given by "Purl Gurl", aka Godzilla
aka Kira. He/she/it is a troll who comes here for the
sole purpose of inciting arguments, sowing disinformation
and misleading beginners with false advice.
--
Helgi Briem hbriem AT simnet DOT is

Excuse the munged address. My last
e-mail address was killed by spammers.