Re: When does a hash of lists get defined?
Actually, those mean different things. Neither autovivifies, which was
what Doug was seeking to understand.
Both
defined $phash{D}[3]
and
exists $phash{D}[3]
autovivify $phash{D}.
- Bruce
'defined' will autovivify, 'exists' will not. I'll leave it up to
Doug to decide if knowing that helps.
Stewart
--
Stewart Leicester | JenSoft Technologies, LLC
Per Ardua Ad Astra | mailto:[EMAIL PROTECTED]
Re: When does a hash of lists get defined?
On 4/5/06 Stewart Leicester wrote:
Bruce Van Allen wrote:
Both
defined $phash{D}[3]
and
exists $phash{D}[3]
autovivify $phash{D}.
- Bruce
'defined' will autovivify, 'exists' will not. I'll leave it up to
Doug to decide if knowing that helps.
Oh? Try this:
#!/usr/bin/perl -w
use strict;
my %hash= (
A = [qw/a0 a1 a2/],
);
# $hash{A}
if (defined $hash{A}[2]) {
print OK \$hash{A}[2] defined\n
}
if (exists $hash{A}[2]) {
print OK \$hash{A}[2] exists\n
}
# test defined() on $hash{B}
if (defined $hash{B}[2]) {
print OK \$hash{B}[2] defined\n
} elsif (exists $hash{B}) {
print OK \$hash{B} exists: autovivified from defined()\n
}
# test exists() on $hash{D}
if (exists $hash{D}[2]) {
print OK \$hash{D}[2] exists\n
} elsif (exists $hash{D}) {
print OK \$hash{D} exists: autovivified from exists()\n
}
__END__
prints:
OK $hash{A}[2] defined
OK $hash{A}[2] exists
OK $hash{B} exists: autovivified from defined()
OK $hash{D} exists: autovivified from exists()
The autovivification is happening when the values are dereferenced.
The expression
exists $hash{D}[2]
is testing the existence of the third element in the array ref
ostensibly stored in $hash{D}, so $hash{D} gets autovivified to allow
the test.
1;
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: When does a hash of lists get defined?
On Apr 5, 2006, at 11:41 AM, Stewart Leicester wrote:
Actually, those mean different things. Neither autovivifies, which
was
what Doug was seeking to understand.
Both
defined $phash{D}[3]
and
exists $phash{D}[3]
autovivify $phash{D}.
- Bruce
'defined' will autovivify, 'exists' will not.
No, Bruce is right. When used with nested structures, both defined()
and exists() will create the hash element D, and store a reference
to an anonymous array in it.
But don't take my word for it - just ask Perl. Here's a simple test:
#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;
my %def_hash;
my %ex_hash;
my $foo = defined($def_hash{'D'}[3]);
print Using defined():\n, Dumper(\%def_hash), \n;
my $bar = exists($ex_hash{'D'}[3]);
print Using exists():\n, Dumper(\%ex_hash), \n;
This prints:
Using defined():
$VAR1 = {
'D' = []
};
Using exists():
$VAR1 = {
'D' = []
};
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
Re: When does a hash of lists get defined?
At 08:41 -0700 4/5/06, Stewart Leicester wrote: 'defined' will autovivify, 'exists' will not. I'll leave it up to Doug to decide if knowing that helps. The Camel book, page 710 in the third edition is very clear that exists goes the same way as defined. But perl has gone through a couple of new versions since it was written. Thanks to Stewart who did get me on the right track by mentioning exists. That's where I found autovivification mentioned in the Bible. It also says there: This behavior is likely to be fixed in a future release. In 5.8.1-RC3 it hasn't changed. I wonder if the comment refers to perl6 ? Do those fellows know about it? The solution for my problem was to test just the hash element without looking at the underlying list item. Exists and defined both work that way without behaving like the Creator. Checking for the list item = also works if the vivifivation has occurred. I appreciate the help from the list -- -- Science is the business of discovering and codifying the rules and methods employed by the Intelligent Designer. Religions provide myths to mollify the anxiety experienced by those who choose not to participate. --
Re: When does a hash of lists get defined?
'defined' will autovivify, 'exists' will not. I'll leave it up to
Doug to decide if knowing that helps.
The Camel book, page 710 in the third edition is very clear that
exists goes the same way as defined. But perl has gone through a
couple of new versions since it was written.
Thanks to Stewart who did get me on the right track by mentioning
exists. That's where I found autovivification mentioned in the Bible.
It also says there:
This behavior is likely to be fixed in a future release.
In 5.8.1-RC3 it hasn't changed.
I wonder if the comment refers to perl6 ? Do those fellows know about
it?
I'm going to shoot myself in the foot before I check the docs, but I
look at the look-ahead and look-behind perl has to take with
if ( funxyz( $a_hash{ D } )
and
if ( funxyz( $a_hash_ref{ D }[ $x ] )
and I think I don't want perl trying to differentiate what exists() and
defined() do in any but the most simple case.
I think the English semantics of defined vs. exists is plenty to deal
with, anyway.
The solution for my problem was to test just the hash element without
looking at the underlying list item. Exists and defined both work that
way without behaving like the Creator. Checking for the list item =
also works if the vivifivation has occurred.
if ( defined( $a_hash_ref ) $defined( $a_hash_ref{ D } )
defined( $a_hash_ref{ D }[ $x ] ) )
although we usually know which of those tests we can leave out if we
stop to think.
Re: When does a hash of lists get defined?
'defined' will autovivify, 'exists' will not. No, Bruce is right. When used with nested structures, both defined() and exists() will create the hash element D, and store a reference to an anonymous array in it. But don't take my word for it - just ask Perl. Here's a simple test: Oops, you're right, I'm wrong. Certainly caused a quick discussion, though, didn't it? :-) I was thinking of this from the docs: The element is not autovivified if it doesn't exist. but obviously forgot about the creation of intervening elements. Teach me to reply before reviewing! Stewart -- Stewart Leicester | JenSoft Technologies, LLC Per Ardua Ad Astra | mailto:[EMAIL PROTECTED]
When does a hash of lists get defined?
While messing with CGI POSTed data I got trapped by this one.
Version 5.8.1-RC3 for Mac OS 10.3.9
It appears that the hash element D gets defined in the process of testing to
see if an element in the associated string is defined. The last if below takes
the else route.
Is that normal? Does it somehow make sense?
%phash = ();
foreach $jill (A, B, C)
{
for ($lynn = 0; $lynn3; $lynn++)
{
$phash{$jill}[$lynn] = $jill$lynn;
print \$phash{$jill}[$lynn] = $phash{$jill}[$lynn]\n;
}
}
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
if (! defined $phash{D}[3])
{
print \$phash{D}[3] is undefined. We expected that too.\n;
}
if (! defined $phash{D})
{
print \$phash{D} is undefined\n;
}
else
{
print \$phash{D} got defined - why?\n;
}
__END__
--
Applescript syntax is like English spelling:
Roughly, but not thoroughly, thought through.
Re: When does a hash of lists get defined?
On 2006.4.5, at 09:36 AM, Doug McNutt wrote:
While messing with CGI POSTed data I got trapped by this one.
Version 5.8.1-RC3 for Mac OS 10.3.9
It appears that the hash element D gets defined in the process of
testing to see if an element in the associated string is defined. The
last if below takes the else route.
Is that normal? Does it somehow make sense?
%phash = ();
foreach $jill (A, B, C)
{
for ($lynn = 0; $lynn3; $lynn++)
{
$phash{$jill}[$lynn] = $jill$lynn;
print \$phash{$jill}[$lynn] = $phash{$jill}[$lynn]\n;
}
}
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
I should run the code before hazarding guesses, but I'm guessing you
find it is not defined above,
if (! defined $phash{D}[3])
{
print \$phash{D}[3] is undefined. We expected that too.\n;
}
... but defined after this one is done, So that the above two would
show is undefined, but the next would show got defined.
The reason I would guess this is that perl does automagically define
things in a lot of cases where other languages (like java) would throw
fits, I mean, throw exceptions. Perl is designed from the point of view
that the programmer thought he knew what he was doing, which, from a
purely mathematical point of view, is dangerous, but in the real world
is often the desired path.
Leaving the deep philosophy aside, if $phash{D) is not defined, there
are three or four ways to parse $phash{D}[3]. The java way would be
(I think) to throw the conniption, I mean, exception: Can't access an
array off a null pointer. Another way might be to short-circuit the
test, if $phash{D} is not defined, no way can anything referenced off
it be defined. But that path requires intelligence which we have not
yet been able to give programming languages and expect them to
completely parse any program in anything approaching determinant time.
{Oh. Wait. One more path I gotta check before I call this either valid
or invalid. Oh, wait, ...}
So perl simply defines the thing so that the rest of the test can
complete, as I understand it.
if (! defined $phash{D})
{
print \$phash{D} is undefined\n;
}
else
{
print \$phash{D} got defined - why?\n;
}
__END__
--
Applescript syntax is like English spelling:
Roughly, but not thoroughly, thought through.
Yeah, and Applescript does a bit more than perl on the trying to read
the programmer's mind, but it was a really bizarre programmer's mind it
was trained, I mean programmed to read.
8-*
Re: When does a hash of lists get defined?
On 4/4/06 Doug McNutt wrote:
While messing with CGI POSTed data I got trapped by this one.
Version 5.8.1-RC3 for Mac OS 10.3.9
It appears that the hash element D gets defined in the process of
testing to see if an element in the associated string is defined. The
last if below takes the else route.
Is that normal? Does it somehow make sense?
%phash = (); foreach $jill (A, B, C)
{ for ($lynn = 0; $lynn3; $lynn++) { $phash{$jill}[$lynn] =
$jill$lynn; print \$phash{$jill}[$lynn] = $phash{$jill}[$lynn]\n;
}
}
if (! defined $phash{D})
{ print \$phash{D} is undefined, We expected that.\n;
}
if (! defined $phash{D}[3])
It happened right here.
See perldoc perlref, especially autovivification.
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: When does a hash of lists get defined?
...
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
Instead of
defined $phash{D}
use
exists $phash{D}
This has bitten me before.
Stewart
--
Stewart Leicester | JenSoft Technologies, LLC
Per Ardua Ad Astra | mailto:[EMAIL PROTECTED]
Re: When does a hash of lists get defined?
On 4/4/06 Stewart Leicester wrote:
if (! defined $phash{D})
{
print \$phash{D} is undefined, We expected that.\n;
}
Instead of
defined $phash{D}
use
exists $phash{D}
Actually, those mean different things. Neither autovivifies, which was
what Doug was seeking to understand.
Both
defined $phash{D}[3]
and
exists $phash{D}[3]
autovivify $phash{D}.
1;
- Bruce
__bruce__van_allen__santa_cruz__ca__
