prevent further hash auto-vivification

[ivowel]

dear perl experts: how can I stop perl from auto-vivifying new keys in
a hash? this seems like something that everyone would want as an
optional feature in an object oriented context, isn't it? sincerely,
/iaw

 

[DJ Stunks]

dear perl experts: how can I stop perl from auto-vivifying new keys in
a hash? this seems like something that everyone would want as an
optional feature in an object oriented context, isn't it?

http://www.perlarchive.com/articles/perl/ug0002.shtml

-jp

 

[boyd]

Use exists() to check for their presence before accessing them.

perldoc -f exists

sherm--

Not true. Exists will cause them to be vivified see the reference
quoted before:
http://www.perlarchive.com/articles/perl/ug0002.shtml

 

[Paul Lalli]

Not true. Exists will cause them to be vivified see the reference
quoted before:
http://www.perlarchive.com/articles/perl/ug0002.shtml

Did you read that article? Using exists() does NOT cause a hash level
to be autovivified. Accessing a level on the way towards using
exists() does. Therefore, you have to use exists on all levels that
you want to test:

if (exists $h{'baz'} and exists $h{'baz'}{'alpha'}) { ... }
rather than simply:
if (exists $h{'baz'}) { ... }

Paul Lalli

 

[boyd]

Not true. Using "exist() to check for their presence before accessing
them" yields a way to "stop perl from auto-vivifying new keys in a
hash". That it won't prevent autovivification at some shallower levels
when accessing a complex data structure is a whole another story and
only means that you have to apply the same technique repeatedly and if
you end up doing so quite often or otherwise find it convenient, then
write some code that will factorize that apart, or find a module that
addresses the issue.


Michele

Sorry. I didn't read the question and/or article carefully enough. You
are correct. In other words: exists($ref->{a}) will not cause $ref->{a}
to be created, but exists($ref->{a}->{b}) will cause $ref->{a} to be
created as an empty hash. Right?

Thanks.

Boyd

 

[DJ Stunks]

Sorry. I didn't read the question and/or article carefully enough. You
are correct. In other words: exists($ref->{a}) will not cause $ref->{a}
to be created, but exists($ref->{a}->{b}) will cause $ref->{a} to be
created as an empty hash. Right?

don't ask, try! you could whip up a script to test that in about 4
lines

-jp

 

[boyd]

don't ask, try! you could whip up a script to test that in about 4
lines

-jp

That's what I did. Except I did it within the debugger: perl -de1

I posted my question sort of rhetorically...

Thanks.
Boyd

 

[Ben Morrow]

Quoth (e-mail address removed):

dear perl experts: how can I stop perl from auto-vivifying new keys in
a hash? this seems like something that everyone would want as an
optional feature in an object oriented context, isn't it? sincerely,

As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
from being added in any way (including autoviv). This feature was added
to support OOP, IIRC (it is a replacement for the deprecated pseudohash
semantics).

Ben

 

[Uri Guttman]

b> In article <[email protected]>,

b> That's what I did. Except I did it within the debugger: perl -de1

b> I posted my question sort of rhetorically...

and you could read the article mentioned. it covers autoviv, exists and
all related stuff. i should know.

uri

 

[Uri Guttman]

BM> Quoth (e-mail address removed):
BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
BM> from being added in any way (including autoviv). This feature was added
BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
BM> semantics).

i wouldn't say hash locking had anything to do with psuedo hashes.
psuedos were intended to be a fast way to do object and look up their
attributes. it was an unholy mess and was rightly ripped out of perl (i
think it was finally removed in 5.8 after being deprecated for years).

maybe the locked hashes are useful to various OO implementation styles
(inside out object don't need that AFAIK) but they aren't similar to
psuedo hashes in any way i can see.

uri

 

[Ben Morrow]

BM> Quoth (e-mail address removed):

BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
BM> from being added in any way (including autoviv). This feature was added
BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
BM> semantics).

i wouldn't say hash locking had anything to do with psuedo hashes.
psuedos were intended to be a fast way to do object and look up their
attributes. it was an unholy mess and was rightly ripped out of perl (i
think it was finally removed in 5.8 after being deprecated for years).

No, they were removed in 5.9.

maybe the locked hashes are useful to various OO implementation styles
(inside out object don't need that AFAIK) but they aren't similar to
psuedo hashes in any way i can see.

As of 5.9 fields.pm is implemented in terms of locked hashes instead of
phashes. This is what they were added to perl for: to keep the
'attribute checking' nature of phashes, which was deemed to be a benefit
of using fields.pm.

IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
use Anno's new 'fieldhashes', which cope correctly with
threads/overloading/re-blessing.

Ben

 

[Brian McCauley]

BM> Quoth (e-mail address removed):

BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
BM> from being added in any way (including autoviv). This feature was added
BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
BM> semantics).

i wouldn't say hash locking had anything to do with psuedo hashes.
psuedos were intended to be a fast way to do object and look up their
attributes. it was an unholy mess and was rightly ripped out of perl (i
think it was finally removed in 5.8 after being deprecated for years).

maybe the locked hashes are useful to various OO implementation styles
(inside out object don't need that AFAIK) but they aren't similar to
psuedo hashes in any way i can see.

....appart from the obvious similarity that pseudo-hashes had fixed keys
in exactly the same way as locked hashes have.

 

[ivowel]

thank you, everybody. Ben---this was exactly what I wanted.

Regards,

/iaw

 

[Uri Guttman]

BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
BM> from being added in any way (including autoviv). This feature was added
BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
BM> semantics).
BM> ...appart from the obvious similarity that pseudo-hashes had fixed keys
BM> in exactly the same way as locked hashes have.

but they weren't 'fixed'. you could always modify the hash in the 0 slot
of the psuedohash's array after creation. only the predefined keys would
be properly converted at compile time but keys added later could still
be looked up at runtime (and even more slowly than a regular hash!). so
psuedohashes didn't completely lock up the attributes anyhow.

uri

 

[Uri Guttman]

BM> As of 5.9 fields.pm is implemented in terms of locked hashes instead of
BM> phashes. This is what they were added to perl for: to keep the
BM> 'attribute checking' nature of phashes, which was deemed to be a benefit
BM> of using fields.pm.

BM> IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
BM> use Anno's new 'fieldhashes', which cope correctly with
BM> threads/overloading/re-blessing.

i tend to not use much inheritance as i prefer delegation in
general. objects owning objects makes more sense to me than objects
being a variant of another object. with delegation you don't worry about
sharing attributes and you should have no issues with those last issues
you mentioned. also delegation is a looser coupling than inheritance and
i am very much in favor of that.

uri

 

[Ben Morrow]

BM> As of 5.9 fields.pm is implemented in terms of locked hashes instead of
BM> phashes. This is what they were added to perl for: to keep the
BM> 'attribute checking' nature of phashes, which was deemed to be a benefit
BM> of using fields.pm.

BM> IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
BM> use Anno's new 'fieldhashes', which cope correctly with
BM> threads/overloading/re-blessing.

i tend to not use much inheritance as i prefer delegation in
general. objects owning objects makes more sense to me than objects
being a variant of another object. with delegation you don't worry about
sharing attributes and you should have no issues with those last issues
you mentioned.

Threads and GC will still be an issue. When a variable is cloned to
create a new thread, its refaddr changes, so you need a CLONE method to
deal with that; and when a variable is destroyed its fields will not be,
so you need a DESTROY method to handle that. Fieldhashes handle both
those cases for you, cleanly.

Ben

 

[Uri Guttman]

BM> As of 5.9 fields.pm is implemented in terms of locked hashes instead of
BM> phashes. This is what they were added to perl for: to keep the
BM> 'attribute checking' nature of phashes, which was deemed to be a benefit
BM> of using fields.pm.BM> IOO don't use locked hashes; but as of 5.10 they will (or can, anyway)
BM> use Anno's new 'fieldhashes', which cope correctly with
BM> threads/overloading/re-blessing.
BM> Threads and GC will still be an issue. When a variable is cloned to
BM> create a new thread, its refaddr changes, so you need a CLONE method to
BM> deal with that; and when a variable is destroyed its fields will not be,
BM> so you need a DESTROY method to handle that. Fieldhashes handle both
BM> those cases for you, cleanly.

all these side issues are why i push event loops over threads. but
enough of that for now.

uri

 

[cmic]

Hello.
(e-mail address removed) a écrit :

thank you, everybody. Ben---this was exactly what I wanted.

I'm sorry to a bit too late. Can I add something (and forgive me if it
I'm wrong )
There is a module called Tie::Hash::FixedKeys which can do the work for
you. If you try to insert a key which is not "authorized", Perl will
throw a run-time warning.

http://www.annocpan.org/~DAVECROSS/Tie-Hash-FixedKeys-1.10/lib/Tie/Hash/FixedKeys.pm

Not tested, though.