[32572] in Perl-Users-Digest
Perl-Users Digest, Issue: 3841 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Dec 19 16:09:25 2012
Date: Wed, 19 Dec 2012 13:09:12 -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 Wed, 19 Dec 2012 Volume: 11 Number: 3841
Today's topics:
Examining the existence of a hash key instantiates high <news@lawshouse.org>
Re: Examining the existence of a hash key instantiates <mghicks@gmail.com>
Re: Examining the existence of a hash key instantiates <ben@morrow.me.uk>
Re: Examining the existence of a hash key instantiates <derykus@gmail.com>
Re: Examining the existence of a hash key instantiates <peter@makholm.net>
Re: Examining the existence of a hash key instantiates <rweikusat@mssgmbh.com>
Re: Examining the existence of a hash key instantiates <rweikusat@mssgmbh.com>
Re: Examining the existence of a hash key instantiates <ben@morrow.me.uk>
Re: Examining the existence of a hash key instantiates <rweikusat@mssgmbh.com>
Re: Examining the existence of a hash key instantiates <ben@morrow.me.uk>
Re: Examining the existence of a hash key instantiates <rweikusat@mssgmbh.com>
Re: Examining the existence of a hash key instantiates <news@lawshouse.org>
Re: Examining the existence of a hash key instantiates <news@lawshouse.org>
Re: Examining the existence of a hash key instantiates <willem@turtle.stack.nl>
Re: Examining the existence of a hash key instantiates <hjp-usenet2@hjp.at>
Re: Examining the existence of a hash key instantiates <hjp-usenet2@hjp.at>
Re: Examining the existence of a hash key instantiates <willem@turtle.stack.nl>
Re: Examining the existence of a hash key instantiates <hansmu@xs4all.nl>
Re: help - how to find what is the code for "+/-" symbo (Seymour J.)
Re: help - how to find what is the code for "+/-" symbo <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 18 Dec 2012 21:50:08 +0000
From: Henry Law <news@lawshouse.org>
Subject: Examining the existence of a hash key instantiates higher level keys
Message-Id: <p8adnWxSG4GNeE3NnZ2dnUVZ8uidnZ2d@giganews.com>
I'm sure this is working as designed but it caught me out so I'm posting
here in the hopes that they next guy who wears out his keyboard trying
to find the source of this error will find it!
It's easiest to explain the behaviour with a short program:
#!/usr/bin/perl
use strict;
use warnings;
use 5.010;
my $hash = { one=> { a=>'a', b=>'b' } };
say "\$hash->{three}{one} doesn't exist"
unless exists $hash->{three}{one};
exists $hash->{three}{one}{a};
say "\$hash->{three}{one} now exists! Surely I didn't create it?"
if exists $hash->{three}{one}
./tryout
$hash->{three}{one} doesn't exist
$hash->{three}{one} now exists! Surely I didn't create it?
In other words, examining the existence of a subkey of a key that
doesn't itself exist calls the higher level key into being.
--
Henry Law Manchester, England
------------------------------
Date: Tue, 18 Dec 2012 13:55:52 -0800 (PST)
From: Matt Hicks <mghicks@gmail.com>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <b12e939f-a051-4116-bf05-5499f0c0d64c@googlegroups.com>
> In other words, examining the existence of a subkey of a key that
> doesn't itself exist calls the higher level key into being.
This is called autovivification. See
http://perldoc.perl.org/perlglossary.html#autovivification
http://en.wikipedia.org/wiki/Autovivification
The CPAN also has a module to disable the behavior.
http://search.cpan.org/~vpit/autovivification-0.10/lib/autovivification.pm
------------------------------
Date: Tue, 18 Dec 2012 23:30:29 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <lta7q9-9m81.ln1@anubis.morrow.me.uk>
Quoth Henry Law <news@lawshouse.org>:
> I'm sure this is working as designed but it caught me out so I'm posting
> here in the hopes that they next guy who wears out his keyboard trying
> to find the source of this error will find it!
>
> It's easiest to explain the behaviour with a short program:
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use 5.010;
>
> my $hash = { one=> { a=>'a', b=>'b' } };
> say "\$hash->{three}{one} doesn't exist"
> unless exists $hash->{three}{one};
> exists $hash->{three}{one}{a};
> say "\$hash->{three}{one} now exists! Surely I didn't create it?"
> if exists $hash->{three}{one}
>
> ./tryout
> $hash->{three}{one} doesn't exist
> $hash->{three}{one} now exists! Surely I didn't create it?
>
> In other words, examining the existence of a subkey of a key that
> doesn't itself exist calls the higher level key into being.
Writing a multi-level exists isn't hard:
use Scalar::Util qw/reftype/;
use Carp qw/croak/;
sub mexists {
my $href = shift;
while (my $key = shift) {
ref $href and reftype $href eq "HASH"
or croak "Not a HASH reference";
exists $href->{$key} or return;
$href = $href->{$key};
}
return 1;
}
mexists $hash, qw/three one a/;
Ben
------------------------------
Date: Tue, 18 Dec 2012 21:49:01 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <82276556-375a-48df-8221-18b0c93bf3ed@googlegroups.com>
On Tuesday, December 18, 2012 2:15:59 PM UTC-8, Henry Law wrote:
> On 18/12/12 21:55, Matt Hicks wrote:
>
> >> In other words, examining the existence of a subkey of a key that
>
> >> doesn't itself exist calls the higher level key into being.
>
> >
>
> > This is called autovivification. See
>
>
>
> That something illogical happens is irritating; to find that it's got a
>
> name doesn't make it any less so!
>
>
I think this behaviour will probably be modified/modifiable at some point.
From perldoc -f exist:
...
undef $ref;
if (exists $ref->{"Some key"}) { }
print $ref; # prints HASH(0x80d3d5c)
This surprising autovivification in what does
not at first--or even second--glance appear to
be an lvalue context may be fixed in a future
release.
--
Charles DeRykus
------------------------------
Date: Wed, 19 Dec 2012 10:47:11 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <87vcbyml0g.fsf@vps1.hacking.dk>
"C.DeRykus" <derykus@gmail.com> writes:
> From perldoc -f exist:
> ...
> This surprising autovivification in what does
> not at first--or even second--glance appear to
> be an lvalue context may be fixed in a future
> release.
It is not really specific to exists(). It is probably mostly noted in
the exists() documentation because it might be counter intuitive to the
specific use case for exists.
In general function arguments are considered lvalue context, which
implies autovivification. The reason is that the @_ elements are aliased
to the arguments, which requires the arguments to sort of exists.
I think that the general consensus is that it *is* inconvenient and that
it might have been better if the autovivification only happended is
someone actually used the alias in an actual lvalue context. But I guess
that it is not trivial to implement and it might not be inconvenient
enough to break backwards compatibility.
//Makholm
------------------------------
Date: Wed, 19 Dec 2012 12:54:15 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <87zk1aw6bs.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Henry Law <news@lawshouse.org>:
>> I'm sure this is working as designed but it caught me out so I'm posting
>> here in the hopes that they next guy who wears out his keyboard trying
>> to find the source of this error will find it!
[...]
>> In other words, examining the existence of a subkey of a key that
>> doesn't itself exist calls the higher level key into being.
>
> Writing a multi-level exists isn't hard:
>
> use Scalar::Util qw/reftype/;
> use Carp qw/croak/;
>
> sub mexists {
> my $href = shift;
> while (my $key = shift) {
> ref $href and reftype $href eq "HASH"
> or croak "Not a HASH reference";
According to the documentation, reftype returns the 'reference type'
if the argument is a reference or undef otherwise. Consequently, the
value of
ref($href) and reftype($href) eq 'HASH'
is identical to the value of
reftype($href) eq 'HASH'
------------------------------
Date: Wed, 19 Dec 2012 15:57:29 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <87d2y6yqza.fsf@sapphire.mobileactivedefense.com>
Hans Mulder <hansmu@xs4all.nl> writes:
> On 19/12/12 13:54:15, Rainer Weikusat wrote:
>> According to the documentation, reftype returns the 'reference type'
>> if the argument is a reference or undef otherwise. Consequently, the
>> value of
>>
>> ref($href) and reftype($href) eq 'HASH'
>>
>> is identical to the value of
>>
>> reftype($href) eq 'HASH'
>
> The two expressions have different results when you've done:
>
> $href = bless {}, 0;
>
> But then, you shouldn't do that.
The documentation to bless demands 'Make sure that CLASSNAME is a true
value', IOW, this is an instance of "you must not do that" not "you
shouldn't do that". In the given context, however, this jus means the
original code is not only clumsy but can also be considered broken: It
will descend into objects except if these objects were blessed into a
'class' whose name is equivalent to 'a false value' and insofar this
check is sensible at all, it should be
ref($href) eq 'HASH'
and the original code should really have been (provided descending
into objects whose implementation happens to be an anonymous hash was
actually desired)
ref($href) ne '' and reftype($href) eq 'HASH'
------------------------------
Date: Wed, 19 Dec 2012 16:42:42 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <2d79q9-num1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Henry Law <news@lawshouse.org>:
> >> I'm sure this is working as designed but it caught me out so I'm posting
> >> here in the hopes that they next guy who wears out his keyboard trying
> >> to find the source of this error will find it!
>
> [...]
>
> >> In other words, examining the existence of a subkey of a key that
> >> doesn't itself exist calls the higher level key into being.
> >
> > Writing a multi-level exists isn't hard:
> >
> > use Scalar::Util qw/reftype/;
> > use Carp qw/croak/;
> >
> > sub mexists {
> > my $href = shift;
> > while (my $key = shift) {
> > ref $href and reftype $href eq "HASH"
> > or croak "Not a HASH reference";
>
> According to the documentation, reftype returns the 'reference type'
> if the argument is a reference or undef otherwise. Consequently, the
> value of
>
> ref($href) and reftype($href) eq 'HASH'
>
> is identical to the value of
>
> reftype($href) eq 'HASH'
The latter produces an 'undef' warning if $href is not a ref. It would
have been better if reftype had simply returned false.
Ben
------------------------------
Date: Wed, 19 Dec 2012 17:22:28 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <874njiyn1n.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Henry Law <news@lawshouse.org>:
>> >> I'm sure this is working as designed but it caught me out so I'm posting
>> >> here in the hopes that they next guy who wears out his keyboard trying
>> >> to find the source of this error will find it!
>>
>> [...]
>>
>> >> In other words, examining the existence of a subkey of a key that
>> >> doesn't itself exist calls the higher level key into being.
>> >
>> > Writing a multi-level exists isn't hard:
>> >
>> > use Scalar::Util qw/reftype/;
>> > use Carp qw/croak/;
>> >
>> > sub mexists {
>> > my $href = shift;
>> > while (my $key = shift) {
>> > ref $href and reftype $href eq "HASH"
>> > or croak "Not a HASH reference";
>>
>> According to the documentation, reftype returns the 'reference type'
>> if the argument is a reference or undef otherwise. Consequently, the
>> value of
>>
>> ref($href) and reftype($href) eq 'HASH'
>>
>> is identical to the value of
>>
>> reftype($href) eq 'HASH'
>
> The latter produces an 'undef' warning if $href is not a ref.
As somebody else pointed out: It is possible to bless a reference into
class 0 and in this case, ref will return false (0, to be
precise). And (as I wrote elsewhere), descending into objects whose
implementation happens to be a hash looks like a rather quirky
'feature' to me. Using
ref($href) eq 'HASH'
avoids both problems (descending into objects and the "Possibly
erroneous conversion detected ! Panic in the streets !!" diagnostic).
------------------------------
Date: Wed, 19 Dec 2012 19:28:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <c4h9q9-q7o1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >> >
> >> > ref $href and reftype $href eq "HASH"
> >> > or croak "Not a HASH reference";
> >>
> >> According to the documentation, reftype returns the 'reference type'
> >> if the argument is a reference or undef otherwise. Consequently, the
> >> value of
> >>
> >> ref($href) and reftype($href) eq 'HASH'
> >>
> >> is identical to the value of
> >>
> >> reftype($href) eq 'HASH'
> >
> > The latter produces an 'undef' warning if $href is not a ref.
>
> As somebody else pointed out: It is possible to bless a reference into
> class 0 and in this case, ref will return false (0, to be
> precise). And (as I wrote elsewhere), descending into objects whose
> implementation happens to be a hash looks like a rather quirky
> 'feature' to me. Using
>
> ref($href) eq 'HASH'
>
> avoids both problems (descending into objects and the "Possibly
> erroneous conversion detected ! Panic in the streets !!" diagnostic).
...but introduces the new problem of objects blessed into the class
"HASH", and leaves the (as yet unaddressed) problem of objects which may
or may not be implemented as a hashref but which have an overloaded %{}.
Type-checking in Perl is unfortunately not the least bit easy; anyone
concerned about doing it properly should use something like Params::Util
or the Moose type-checking system. Personally I don't usually bother,
since in fact a simple $href->{$key} will produce an error which is at
least correct, if not as helpful as it might be. I'm beginning to
regret including the specific check in the first place...
Ben
------------------------------
Date: Wed, 19 Dec 2012 20:46:41 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <87zk19ydla.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
[...]
>> >>
>> >> reftype($href) eq 'HASH'
>> >
[...]
>> ref($href) eq 'HASH'
>>
>> avoids both problems (descending into objects and the "Possibly
>> erroneous conversion detected ! Panic in the streets !!" diagnostic).
>
> ...but introduces the new problem of objects blessed into the class
> "HASH", and leaves the (as yet unaddressed) problem of objects which may
> or may not be implemented as a hashref but which have an overloaded
> %{}.
>
> Type-checking in Perl is unfortunately not the least bit easy; anyone
> concerned about doing it properly should use
[the usual suggestion that the solution to any problem is "download
more stuff form the internet"]
Personally, I would omit the check and use something like
sub mexists($@)
{
my $cur;
$cur = shift;
for (@_) {
exists($cur->{$_}) or return;
$cur = $cur->{$_};
}
return 1;
}
and in case I had to deal with input values where this wouldn't work,
I would either extend it to cover these cases as well or get rid of
the 'annoying' inputs, whatever seemed more feasible. In certain
cases, eg the 0 and HASH 'classes', when people are purposely
disregarding recommendations/ requirements in the documentation, they
start to deserve whatever might be hitting them because of that. It
should also be relatively easy to circumvent even the most
sophisticated 'perl argument valdiation system' by runtime-linking
suitable C code into the interpreter, meaning, intentional (or even
accidental) sabotage is always an option.
"It would prefer that you stayed out of its living room because you
weren't invited, not because it has a shotgun."
------------------------------
Date: Tue, 18 Dec 2012 22:15:59 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <G9Cdna2B8fK9dk3NnZ2dnUVZ8tydnZ2d@giganews.com>
On 18/12/12 21:55, Matt Hicks wrote:
>> In other words, examining the existence of a subkey of a key that
>> doesn't itself exist calls the higher level key into being.
>
> This is called autovivification. See
That something illogical happens is irritating; to find that it's got a
name doesn't make it any less so!
Anyway; working as designed, as I suspected. Thank you for the useful
references.
--
Henry Law Manchester, England
------------------------------
Date: Tue, 18 Dec 2012 22:22:55 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <F-SdnYkeYesicU3NnZ2dnUVZ8g-dnZ2d@giganews.com>
On 18/12/12 21:55, Matt Hicks wrote:
>> In other words, examining the existence of a subkey of a key that
>> doesn't itself exist calls the higher level key into being.
>
> This is called autovivification. See
>
> http://perldoc.perl.org/perlglossary.html#autovivification
I should have read the reference more clearly before my post a few
minutes ago. The situation here isn't quite the same as the one in my
program. In the quoted example
$a[5][5][5][5][5] = "quintet"
It's clear that for the text item to exist at the fifth level the other
four have to exist too. It's therefore logical to create them; how
could it be otherwise.
But in my program all I was doing was examining the existence of
$hash->{three}{one}{a} when $hash->{three} didn't exist. Since it
didn't, it would have been impossible for any subkey such as {one},
still less {one}{a}, to exist either; a more logical implementation of
"exists" would have stopped at that point, returned FALSE and not
instantiated {three}.
--
Henry Law Manchester, England
------------------------------
Date: Tue, 18 Dec 2012 23:06:42 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <slrnkd1to2.1hu6.willem@turtle.stack.nl>
Henry Law wrote:
) On 18/12/12 21:55, Matt Hicks wrote:
)>> In other words, examining the existence of a subkey of a key that
)>> doesn't itself exist calls the higher level key into being.
)>
)> This is called autovivification. See
)>
)> http://perldoc.perl.org/perlglossary.html#autovivification
)
) I should have read the reference more clearly before my post a few
) minutes ago. The situation here isn't quite the same as the one in my
) program. In the quoted example
)
) $a[5][5][5][5][5] = "quintet"
)
) It's clear that for the text item to exist at the fifth level the other
) four have to exist too. It's therefore logical to create them; how
) could it be otherwise.
)
) But in my program all I was doing was examining the existence of
) $hash->{three}{one}{a} when $hash->{three} didn't exist.
But surely, $hash->{three} must exist, for otherwise, how could you examine
the existence of an element inside it? So therefore it was created for you.
By examining the existence of $hash->{three}->{one}->{a}, you are
assuming thah $hash->{three} is a hash reference, which contains
$hash->{three}->{one}, also a hash reference. As it turns out, they
were not, but by assuming that they are, they come into existence.
PS: Any other language would have thrown an exception.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Wed, 19 Dec 2012 10:11:19 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <slrnkd315n.cn.hjp-usenet2@hrunkner.hjp.at>
On 2012-12-18 23:06, Willem <willem@turtle.stack.nl> wrote:
> Henry Law wrote:
> ) But in my program all I was doing was examining the existence of
> ) $hash->{three}{one}{a} when $hash->{three} didn't exist.
>
> But surely, $hash->{three} must exist, for otherwise, how could you
> examine the existence of an element inside it?
If $hash->{three} doesn't exist, $hash->{three}{one}{a} can't exist
either, so exists($hash->{three}{one}{a}) could return false as soon as
it detects that $hash->{three} doesn't exist. There is no need to create
those intermediate levels.
> PS: Any other language would have thrown an exception.
Perl does throw an exception instead of autovivifying in a similar case:
% perl -Mstrict -MData::Dumper -E '
my $hash = {};
say %{ $hash->{three}{one} };
say Dumper $hash'
Can't use an undefined value as a HASH reference at -e line 3.
But curiosly, it doesn't if I get try to get the keys of the
non-existent hash:
% perl -Mstrict -MData::Dumper -E '
my $hash = {};
say keys %{ $hash->{three}{one} };
say Dumper $hash'
$VAR1 = {
'three' => {
'one' => {}
}
};
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 19 Dec 2012 10:13:16 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <slrnkd319c.cn.hjp-usenet2@hrunkner.hjp.at>
On 2012-12-19 05:49, C.DeRykus <derykus@gmail.com> wrote:
> I think this behaviour will probably be modified/modifiable at some point.
>
> From perldoc -f exist:
> ...
> undef $ref;
> if (exists $ref->{"Some key"}) { }
> print $ref; # prints HASH(0x80d3d5c)
>
> This surprising autovivification in what does
> not at first--or even second--glance appear to
> be an lvalue context may be fixed in a future
> release.
Ah, I missed that when we last had a discussion about autovivification.
Might have been useful.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Wed, 19 Dec 2012 09:52:03 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <slrnkd33i3.1ltv.willem@turtle.stack.nl>
Peter J. Holzer wrote:
) On 2012-12-18 23:06, Willem <willem@turtle.stack.nl> wrote:
)> Henry Law wrote:
)> ) But in my program all I was doing was examining the existence of
)> ) $hash->{three}{one}{a} when $hash->{three} didn't exist.
)>
)> But surely, $hash->{three} must exist, for otherwise, how could you
)> examine the existence of an element inside it?
)
) If $hash->{three} doesn't exist, $hash->{three}{one}{a} can't exist
) either,
If $hash->{three} doesn't exist, then $hash->{three}{one}{a} is *meaningless*.
The only way it can have meaning is for $hash->{three} to be a hashref.
This: exists $hash->{three}{one}{a}
Means: Take element 'three' of hashref $hash, which is a hashref.
In this hashref, take element 'one', which is a hashref.
In this hashref, take element 'a' and look if it exists.
So, you're telling Perl that $hash->{three} and $hash->{three}{one} are
hashrefs, by using them as such.
You are thinking of multi-level hashes as a single entity when they're not.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Wed, 19 Dec 2012 16:26:17 +0100
From: Hans Mulder <hansmu@xs4all.nl>
Subject: Re: Examining the existence of a hash key instantiates higher level keys
Message-Id: <50d1dc99$0$6856$e4fe514c@news2.news.xs4all.nl>
On 19/12/12 13:54:15, Rainer Weikusat wrote:
> According to the documentation, reftype returns the 'reference type'
> if the argument is a reference or undef otherwise. Consequently, the
> value of
>
> ref($href) and reftype($href) eq 'HASH'
>
> is identical to the value of
>
> reftype($href) eq 'HASH'
The two expressions have different results when you've done:
$href = bless {}, 0;
But then, you shouldn't do that.
-- HansM
------------------------------
Date: Wed, 19 Dec 2012 09:04:40 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: help - how to find what is the code for "+/-" symbol copied from Windows app
Message-Id: <50d1c978$14$fuzhry+tra$mr2ice@news.patriot.net>
In <50cf9402$0$6880$e4fe514c@news2.news.xs4all.nl>, on 12/17/2012
at 10:52 PM, "Dr.Ruud" <rvtol+usenet@xs4all.nl> said:
>And don't forget quotemeta:
What's wrong with use charnames? While \N{foo} may be more verbose
than a hex code, it's also more legible.
--
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: Tue, 18 Dec 2012 23:56:59 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: help - how to find what is the code for "+/-" symbol copied from Windows app
Message-Id: <slrnkd1t5r.6ep.hjp-usenet2@hrunkner.hjp.at>
On 2012-12-16 14:31, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <slrnkcrcv6.htc.hjp-usenet2@hrunkner.hjp.at>, on 12/16/2012
> at 12:43 PM, "Peter J. Holzer" <hjp-usenet2@hjp.at> said:
>>At least an unintended charset conversion can be easily undone
>>with iconv or similar tools
>
> Not when there are no MIME headers.
In the scenario mentioned by Ben (diffs sent by E-Mail) there are.
> Absent charset, there's no way to know what the non-ASCII code points
> are.
Not really a problem in this scenario: There aren't that many plausible
candidates and you have a few good tests to distinguish between right
and wrong: 1: The patch has to apply; 2: The result has to make sense.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
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 3841
***************************************
