[32328] in Perl-Users-Digest
Perl-Users Digest, Issue: 3595 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 19 21:09:46 2012
Date: Thu, 19 Jan 2012 18:09:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 19 Jan 2012 Volume: 11 Number: 3595
Today's topics:
Re: [style] parsing name=value lists <ben@morrow.me.uk>
Re: [style] parsing name=value lists <tadmc@seesig.invalid>
Re: [style] parsing name=value lists (Seymour J.)
Re: [style] parsing name=value lists <ben@morrow.me.uk>
Re: find it, cut it out, find next <rvtol+usenet@xs4all.nl>
Re: lib::libXML parsing comments <ben@morrow.me.uk>
Re: Single-File Inheritance <jimsgibson@gmail.com>
Re: Single-File Inheritance <rweikusat@mssgmbh.com>
Re: Single-File Inheritance <rweikusat@mssgmbh.com>
Re: Single-File Inheritance <rweikusat@mssgmbh.com>
Re: When is @_ undefined? <rweikusat@mssgmbh.com>
Re: When is @_ undefined? (Tim McDaniel)
Re: When is @_ undefined? <rvtol+usenet@xs4all.nl>
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? (Tim McDaniel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 19 Jan 2012 15:32:35 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [style] parsing name=value lists
Message-Id: <jlplu8-br03.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> I want to write some code that will retrieve TXT records containing
> name=value pairs, separated by commas. I'm only interested in specific
> names. The obvious was to do this is something like
>
> my $rr;
> my %names={r=>1, ro=>1};
> my %opt;
> for my $pair (split /;/ $rr) {
> if (/\s*(\w+)=(\w+)\s*$/) {
> if ($names{$1})
> $opt{$1}=$2;
> }
> } else {
> print STDERR, "invalid option $pair\n";
> }
> }
>
> but that looks awkward. Is there a better style?
I might write it like this; you may or may not find it clearer:
my $keys = join "|", map quotemeta,
qw( r ro );
for (split /;/, $rr) {
my ($k, $v) = /^\s* ($keys)=(\w+) \s*$/x
or warn("invalid option $pair\n"), next;
$opt{$k} = $v;
}
This doesn't have quite the same behaviour, of course: it warns about
valid but unrecognised pairs like 'foo=3'. If you don't want that then
you can't avoid two separate checks, but you can always exit the loop
early rather than nesting 'if's. Either
for (split /;/, $rr) {
my ($k, $v) = /^\s*(\w+)=(\w+)\s*$/ or do {
warn "invalid option $pair\n";
next;
};
$names{$k} or next;
$opt{$k} = $v;
}
or, if you're doing a lot of these checks, wrap it in a sub:
sub wnext { warn $_[0]; no warnings "exiting"; next; }
for (split /;/, $rr) {
my ($k, $v) = /^\s*(\w+)=(\w+)\s*$/
or wnext "invalid option $pair\n";
$names{$k} or wnext "unrecognised option $k\n";
$opt{$k} = $v;
}
Ben
------------------------------
Date: Thu, 19 Jan 2012 11:56:56 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: [style] parsing name=value lists
Message-Id: <slrnjhgmop.3mq.tadmc@tadbox.sbcglobal.net>
Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> The obvious was to do this is something like
Err, what is below is not even a Perl program...
> my $rr;
> my %names={r=>1, ro=>1};
You should always enable warnings when developing Perl code...
> my %opt;
> for my $pair (split /;/ $rr) {
There should be a comma between the arguments to split().
$rr contains undef at this point, splitting it is not likely to be
interesting...
> if (/\s*(\w+)=(\w+)\s*$/) {
> if ($names{$1})
Missing opening curly brace.
> $opt{$1}=$2;
> }
> } else {
> print STDERR, "invalid option $pair\n";
> }
> }
>
> but that looks awkward. Is there a better style?
First we need a Perl program, then we could perhaps evaluate its style...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 19 Jan 2012 11:54:30 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: [style] parsing name=value lists
Message-Id: <4f184ac6$2$fuzhry+tra$mr2ice@news.patriot.net>
In <jlplu8-br03.ln1@anubis.morrow.me.uk>, on 01/19/2012
at 03:32 PM, Ben Morrow <ben@morrow.me.uk> said:
> my $keys = join "|", map quotemeta,
> qw( r ro );
The key names are all alphabetic, so the quotemeta shouldn't be
needed.
my $keys = qr/r | ro/;
However, I want to skip the one's I'm not interested in rather than
treating them as errors.
> for (split /;/, $rr) {
> my ($k, $v) = /^\s*(\w+)=(\w+)\s*$/ or do {
> warn "invalid option $pair\n";
> next;
> };
> $names{$k} or next;
> $opt{$k} = $v;
> }
How about
> for (split /;/, $rr) {
> my ($k, $v) = /^\s*(\w+)=(\w+)\s*$/ or do {
> warn "invalid option $pair\n";
> next;
> };
> next unless $names{$k};
> $opt{$k} = $v;
> }
What are the style guidelines for named captures versus numeric
references to unnamed captures versus array assignments of unnamed
captures?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 19 Jan 2012 22:52:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [style] parsing name=value lists
Message-Id: <odjmu8-5m3.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <jlplu8-br03.ln1@anubis.morrow.me.uk>, on 01/19/2012
> at 03:32 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> How about
>
> > for (split /;/, $rr) {
> > my ($k, $v) = /^\s*(\w+)=(\w+)\s*$/ or do {
> > warn "invalid option $pair\n";
> > next;
> > };
> > next unless $names{$k};
> > $opt{$k} = $v;
> > }
>
> What are the style guidelines for named captures versus numeric
> references to unnamed captures versus array assignments of unnamed
> captures?
I would always use list assignment to named variables, where possible,
rather than relying on $1, $2, &c. Named captures are New, so I'm not in
the habit of using them yet, so I have no opinion about them :).
Ben
------------------------------
Date: Thu, 19 Jan 2012 19:18:57 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: find it, cut it out, find next
Message-Id: <4f185e8c$0$6867$e4fe514c@news2.news.xs4all.nl>
On 2012-01-16 04:53, oldyork90 wrote:
> I have a string that contains numbers and ranges of numbers, like
>
> '1 2 4-6 8 20 - 23' which translates as "include numbers 1, 2, 4, 5,
> 6, 8, 20, 21, 22, 23'
perl -Mstrict -wle '
my $data = "1 2 4-6 8 20 - 23 99-100";
my @data = map { s/\s+\z//, s/\A\s+//; length() ? $_ : () }
split /([^0-9]+)/, $data;
for my $i ( 0 .. $#data ) {
splice @data, $i, 1,
( $data[ $i - 1 ] + 1 .. $data[ $i + 1 ] - 1 )
if $data[ $i ] eq "-";
}
print "include numbers ", join ", ", @data;
'
include numbers 1, 2, 4, 5, 6, 8, 20, 21, 22, 23, 99, 100
--
Ruud
------------------------------
Date: Thu, 19 Jan 2012 15:11:36 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: lib::libXML parsing comments
Message-Id: <8eolu8-jg03.ln1@anubis.morrow.me.uk>
Quoth fergus@twig-me-uk.not.here (Fergus McMenemie):
>
> I have to parse an XML document and rewrite it, after sorting some of
> the nodes. Some of these nodes have assocated comments which I have been
> told have to remain beside their node.
>
> However walking the list of nodes returned by XML::LibXML's
> getChildNodes or childNodes I never see XML_COMMENT_NODE returned. It
> looks as though the parser is discarding comments.
Works for me:
#!/opt/perl/bin/perl
use 5.010;
use warnings;
use strict;
use XML::LibXML;
my $X = XML::LibXML->load_xml(IO => \*DATA);
say sprintf "[%s] [%s]", $_->nodeName, $_->textContent
for $X->documentElement->childNodes;
__END__
<?xml version="1.0"?>
<xml>
<!-- comment -->
<element/>
</xml>
gives
[#text] [
]
[#comment] [ comment ]
[#text] [
]
[element] []
[#text] [
]
Can you post a miminal example which doesn't do what you want?
Ben
------------------------------
Date: Thu, 19 Jan 2012 09:28:23 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Single-File Inheritance
Message-Id: <190120120928230263%jimsgibson@gmail.com>
In article <4f178e61$4$fuzhry+tra$mr2ice@news.patriot.net>, Seymour J.
<spamtrap@library.lspace.org.invalid> wrote:
> In <180120121619571440%jimsgibson@gmail.com>, on 01/18/2012
> at 04:19 PM, Jim Gibson <jimsgibson@gmail.com> said:
>
> >I think that is what I am trying to do.
>
> No.
>
> >Perhaps I could explain it better
>
> That's what you wrote the first time; it's not what I'm suggesting.
OK. Then I guess I don't understand your suggestion.
> >by saying "write a parent class that has methods to read the
> >header lines, and child classes that have specialized methods to read
> >and parse subsequent lines."
>
> Why not have the methods for header lines in child classes?
Because the 6 header lines are the same for all types of files. I have
written an open() method in the parent class that given the file path,
opens the file, reads the first 6 lines, and saves the data therein. It
leaves the file open at the 7th record. The open() method is
implemented in the parent class and inherited by the child classes.
What would be the point in duplicating the open method identically in
all the child classes?
Thanks for your input. Sorry I don't understand your points.
--
Jim Gibson
------------------------------
Date: Thu, 19 Jan 2012 18:07:54 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Single-File Inheritance
Message-Id: <87r4yvd0qt.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Jim Gibson <jimsgibson@gmail.com>:
>> <davidp@preshweb.co.uk> wrote:
>> >
>> > Rather than manually stuff @ISA, I'd use 'parent' with the -norequire
>> > option:
>> >
>> > package ConfigFile;
>> > use parent -norequire DataFile;
>> > ...
>>
>> Thanks. This works:
>>
>> use parent -norequire, 'DataFile';
>>
>> although I don't see any advantage over 'our @ISA = ...'
>
> It is, by design, equivalent to
>
> BEGIN { our @ISA = "DataFile" }
>
> and the fact the assignment happens at compile time can be important.
>
> For the few circumstances where keeping a class in the 'wrong' file is a
> good idea, I wouldn't bother with 'parent' and would just use the BEGIN
> above. 'parent' is useful in the normal case, where you need to load the
> parent class as well as inherit from it.
For a lot of not entirely trivial code I have written, this is
actually the common case and not because classes reside in files which
won't be found by the search algorithm which happens to be used by
'use' but because the dependencies among the classes themselves are
too complex to enabling loading modules defining parent classes from
the files defining dependent classes. In this case, I usually load all
modules from the source files containing the main program and declare
dependencies in the classes themselves.
Morale: That someone has never seen code where separating loading of
modules and declaring inheritance relationships was necessary doesn't
exactly make that someone someone who is qualified to judge that this
separation doesn't make sense.
Minor gems:
{
no strict 'refs';
# This is more efficient than push for the new MRO
# at least until the new MRO is fixed
@{"$inheritor\::ISA"} = (@{"$inheritor\::ISA"} , @_);
};
In plain English, this means 'this is a workaround for a bug in some
other code' [which isn't used by default]. And this is - of course -
an atrociously indefficient way to reinvent unshift.
[rw@sapphire]~ $perldoc -f unshift
unshift ARRAY,LIST
Does the opposite of a "shift". Or the opposite of a
"push", depending on how you look at it. Prepends list to the
front of the array, and returns the new number of elements in
the array.
unshift(@ARGV, '-e') unless $ARGV[0] =~ /^-/;
Note the LIST is prepended whole, not one element at a
time, so the prepended elements stay in the same order.
Use "reverse" to do the reverse.
------------------------------
Date: Thu, 19 Jan 2012 18:16:57 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Single-File Inheritance
Message-Id: <87mx9jd0bq.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> {
> no strict 'refs';
> # This is more efficient than push for the new MRO
> # at least until the new MRO is fixed
> @{"$inheritor\::ISA"} = (@{"$inheritor\::ISA"} , @_);
> };
>
> In plain English, this means 'this is a workaround for a bug in some
> other code' [which isn't used by default]. And this is - of course -
> an atrociously indefficient way to reinvent unshift.
It isn't unshift at all, of course, I just mistakenly assumed that it
had to be doing something other than adding elements to the end of a
list ...
------------------------------
Date: Thu, 19 Jan 2012 19:36:24 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Single-File Inheritance
Message-Id: <87ipk7cwnb.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> For the few circumstances where keeping a class in the 'wrong' file is a
>> good idea,
Here's what the Camel book has to say on "using WRONG files" (NB: A
copy of that resides on my bookshelf at home some please spare me the
anti-scientific outcry this time):
Sometimes folks are surprised that including a class in @ISA
doesn't require the appropriate module for you. That's because
Perl's class system is largely orthogonal to its module
system. One file can hold many classes (since they're just
packages), and one package may be mentioned in many files.
But I guess that has also been 'deprecated' by someone meanwhile ...
------------------------------
Date: Thu, 19 Jan 2012 14:21:33 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: When is @_ undefined?
Message-Id: <87ehuv3h8y.fsf@sapphire.mobileactivedefense.com>
Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> writes:
> Am 19.01.2012 04:24, schrieb Shmuel (Seymour J.) Metz:
>> In <s6uju8-tlh2.ln1@anubis.morrow.me.uk>, on 01/18/2012
>> at 10:37 PM, Ben Morrow <ben@morrow.me.uk> said:
>>
>>> It does, but it isn't necessary. Arrays in Perl are guaranteed to
>>> start empty,
>>
>> So they're guarantied to be defined?
>
> perldoc -f defined
> ...Use of "defined" on aggregates (hashes and arrays) is deprecated. It
> used to report whether memory for that aggregate has ever been
> allocated. This behavior may disappear in future versions of Perl...
>
> If we use it anyway (still works in 5.10), we can see this behaviour:
>
> See this:
> perl -E'@a=();sub t{say $_[0] if defined @a}t(1);@a=(1);t(2);@a=();t(3)'
>
> ...prints 2 and 3, but not 1
>
> Both "my @arr" and "my @arr = ()" lead to the same result: an empty
> array (that is not defined, i.e. memory has never been allocated for it).
>
> But why do you care about this at all?
Because he has successfully been fooled into believing that Perl
variables don't start to exist in some well-defined state by the 'use
of uninitialized value!' warning. Given that scalars apparently need to be
'initialized', why would this be any different for other variables?
------------------------------
Date: Thu, 19 Jan 2012 16:11:48 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: When is @_ undefined?
Message-Id: <jf9fc4$ddm$1@reader1.panix.com>
In article <mvtju8-tlh2.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <mmdju8-fme2.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >No, a comma is always the comma operator. In list context it builds a
>> >list, in scalar context it returns its RH argument.
>>
>> As a tangent, is it more correct to say "a LIST in a scalar context
>> evaluates to its length" or "an ARRAY in a scalar context evaluates to
>> its length"?
>
>More generally: a list is a value, like '1'. An array is a variable,
>like '$x'.
Gotcha. Thanks.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Thu, 19 Jan 2012 19:34:28 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: When is @_ undefined?
Message-Id: <4f186230$0$6894$e4fe514c@news2.news.xs4all.nl>
On 2012-01-18 19:01, Shmuel (Seymour J.) Metz wrote:
> Does this work?
>
> my @arglist=();
1. White space is cheap.
2. It has unexpected effects:
perl -wle '
my @arglist = ();
BEGIN { @arglist = ( 4, 5, 6 ) }
print for @arglist;
'
--
Ruud
------------------------------
Date: Thu, 19 Jan 2012 14:10:46 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f186ab6$3$fuzhry+tra$mr2ice@news.patriot.net>
In <4f186230$0$6894$e4fe514c@news2.news.xs4all.nl>, on 01/19/2012
at 07:34 PM, "Dr.Ruud" <rvtol+usenet@xs4all.nl> said:
>1. White space is cheap.
>2. It has unexpected effects:
>perl -wle '
> my @arglist = ();
> BEGIN { @arglist = ( 4, 5, 6 ) }
> print for @arglist;
>'
I printed scalar @arglist and it was zero as expected. What part of
the result was unexpected?
Now, had I gotten '4,5,6' in the output, *that* would have been
unexpected.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 19 Jan 2012 11:37:35 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f1846cf$1$fuzhry+tra$mr2ice@news.patriot.net>
In <87ehuv3h8y.fsf@sapphire.mobileactivedefense.com>, on 01/19/2012
at 02:21 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>Because he has successfully been fooled into believing that Perl
>variables don't start to exist in some well-defined state by the 'use
>of uninitialized value!' warning.
Isn't undef a well defined state?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 19 Jan 2012 22:57:48 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <cojmu8-5m3.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <87ehuv3h8y.fsf@sapphire.mobileactivedefense.com>, on 01/19/2012
> at 02:21 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>
> >Because he has successfully been fooled into believing that Perl
> >variables don't start to exist in some well-defined state by the 'use
> >of uninitialized value!' warning.
>
> Isn't undef a well defined state?
I think that was Rainer's point: Perl variables are never 'undefined' in
the sense of the C standard, so the 'uninitialized value' warnings tend
to be more noise than useful. They certainly aren't equivalent to the
'variable used without being assigned a value' warnings C compilers are
so fond of, which often do indicate genuine bugs.
In perl's defence, they were much more useful back before 'my' and
'strict' were invented. In Perl 4 it was terribly easy to misspell a
variable name, and the only notice you got was (if you were lucky) an
'uninitialized value' warning. IMHO in Perl 5 they are redundant.
Ben
------------------------------
Date: Thu, 19 Jan 2012 23:01:29 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <9vjmu8-5m3.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <4f186230$0$6894$e4fe514c@news2.news.xs4all.nl>, on 01/19/2012
> at 07:34 PM, "Dr.Ruud" <rvtol+usenet@xs4all.nl> said:
>
> >1. White space is cheap.
> >2. It has unexpected effects:
>
> >perl -wle '
> > my @arglist = ();
> > BEGIN { @arglist = ( 4, 5, 6 ) }
> > print for @arglist;
> >'
>
> I printed scalar @arglist and it was zero as expected. What part of
> the result was unexpected?
>
> Now, had I gotten '4,5,6' in the output, *that* would have been
> unexpected.
If you write
for (1..2) {
my @arglist;
BEGIN { @arglist = 4, 5, 6 }
say $_, @arglist;
}
you get '456' the first time only. This is because of the details of how
'my' works, and I would agree that *this* result is the unexpected one.
Ben
------------------------------
Date: Thu, 19 Jan 2012 23:38:52 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: When is @_ undefined?
Message-Id: <jfa9ic$ph8$1@reader1.panix.com>
In article <cojmu8-5m3.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>I think that was Rainer's point: Perl variables are never 'undefined' in
>the sense of the C standard, so the 'uninitialized value' warnings tend
>to be more noise than useful. They certainly aren't equivalent to the
>'variable used without being assigned a value' warnings C compilers are
>so fond of, which often do indicate genuine bugs.
Using a variable without it having been assigned a value may indeed
be a genuine bug.
>In perl's defence, they were much more useful back before 'my' and
>'strict' were invented. In Perl 4 it was terribly easy to misspell a
>variable name, and the only notice you got was (if you were lucky) an
>'uninitialized value' warning. IMHO in Perl 5 they are redundant.
Yesterday, I ran across code where $tbl{FACIlITY} was used. Luckily,
he used cut-and-paste or autocomplete, so it was actually consistent
in about 9 different uses! But a bad hash key is something that "use
strict" doesn't catch.
Personally, I am a great fan of initializing variables, even to their
defaults. I use it to indicate "I've considered what the initial
value should be, and it should be what I indicate". If I leave the
initial value unset, then either
- it is set in all code paths, and probably not far in the future
- I overlooked something
So I find it valuable, even when it's
my @keys = ();
or (untested code)
my $max = undef;
foreach (@values) {
$max = $_ if ! defined $max || $max < $_;
}
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3595
***************************************
