prevent further hash auto-vivification

Discussion in 'Perl Misc' started by ivowel@gmail.com, Nov 24, 2006.

  1. Guest

    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
    , Nov 24, 2006
    #1
    1. Advertising

  2. DJ Stunks Guest

    wrote:
    > 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
    DJ Stunks, Nov 24, 2006
    #2
    1. Advertising

  3. boyd Guest

    In article <>,
    Sherm Pendley <> wrote:

    > writes:
    >
    > > dear perl experts: how can I stop perl from auto-vivifying new keys in
    > > a hash?

    >
    > 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
    boyd, Nov 24, 2006
    #3
  4. Paul Lalli Guest

    boyd wrote:
    > In article <>,
    > Sherm Pendley <> wrote:
    >
    > > writes:
    > >
    > > > dear perl experts: how can I stop perl from auto-vivifying new keys in
    > > > a hash?

    > >
    > > Use exists() to check for their presence before accessing them.
    > >
    > > perldoc -f exists

    > 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
    Paul Lalli, Nov 24, 2006
    #4
  5. boyd Guest

    In article <>,
    Michele Dondi <> wrote:

    > On Fri, 24 Nov 2006 21:38:35 GMT, boyd <> wrote:
    >
    > >> > dear perl experts: how can I stop perl from auto-vivifying new keys in
    > >> > a hash?
    > >>
    > >> 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

    >
    > 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
    boyd, Nov 24, 2006
    #5
  6. DJ Stunks Guest

    boyd wrote:
    > 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
    DJ Stunks, Nov 24, 2006
    #6
  7. boyd Guest

    In article <>,
    "DJ Stunks" <> wrote:

    > boyd wrote:
    > > 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


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

    I posted my question sort of rhetorically...

    Thanks.
    Boyd
    boyd, Nov 25, 2006
    #7
  8. Ben Morrow Guest

    Quoth :
    >
    > 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

    --
    Raise your hand if you're invulnerable.
    []
    Ben Morrow, Nov 25, 2006
    #8
  9. Uri Guttman Guest

    >>>>> "b" == boyd <> writes:

    b> In article <>,
    b> "DJ Stunks" <> wrote:

    >> boyd wrote:
    >> > 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


    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 ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
    Uri Guttman, Nov 25, 2006
    #9
  10. Uri Guttman Guest

    >>>>> "BM" == Ben Morrow <> writes:

    BM> Quoth :
    >>
    >> 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,


    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

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
    Uri Guttman, Nov 25, 2006
    #10
  11. Ben Morrow Guest

    Quoth Uri Guttman <>:
    > >>>>> "BM" == Ben Morrow <> writes:

    >
    > BM> Quoth :
    > >>
    > >> 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,

    >
    > 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

    --
    The cosmos, at best, is like a rubbish heap scattered at random.
    Heraclitus
    Ben Morrow, Nov 25, 2006
    #11
  12. Uri Guttman wrote:
    > >>>>> "BM" == Ben Morrow <> writes:

    >
    > BM> Quoth :
    > >>
    > >> 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,

    >
    > 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.
    Brian McCauley, Nov 25, 2006
    #12
  13. Guest

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

    Regards,

    /iaw


    Ben Morrow wrote:
    > Quoth :
    > >
    > > 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
    >
    > --
    > Raise your hand if you're invulnerable.
    > []
    , Nov 25, 2006
    #13
  14. Uri Guttman Guest

    >>>>> "BM" == Brian McCauley <> writes:

    BM> Uri Guttman wrote:
    >> >>>>> "BM" == Ben Morrow <> writes:

    >>

    BM> Quoth :
    >> >>
    >> >> 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,

    >>

    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.


    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 ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
    Uri Guttman, Nov 25, 2006
    #14
  15. Uri Guttman Guest

    >>>>> "BM" == Ben Morrow <> writes:


    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

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
    Uri Guttman, Nov 26, 2006
    #15
  16. Ben Morrow Guest

    Quoth Uri Guttman <>:
    > >>>>> "BM" == Ben Morrow <> writes:

    >
    >
    > 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

    --
    I have two words that are going to make all your troubles go away.
    "Miniature". "Golf".
    []
    Ben Morrow, Nov 26, 2006
    #16
  17. Uri Guttman Guest

    >>>>> "BM" == Ben Morrow <> writes:

    BM> Quoth Uri Guttman <>:
    >> >>>>> "BM" == Ben Morrow <> writes:

    >>
    >>

    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.


    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

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
    Uri Guttman, Nov 27, 2006
    #17
  18. cmic Guest

    Hello.
    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 :cool: )
    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.
    --
    cmic just another Perl user (not a Guru)

    >
    > Regards,
    >
    > /iaw
    >
    >
    > Ben Morrow wrote:
    > > Quoth :
    > > >
    > > > 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
    > >
    > > --
    > > Raise your hand if you're invulnerable.
    > > [..uk]
    cmic, Nov 27, 2006
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jason
    Replies:
    2
    Views:
    2,519
    =?Utf-8?B?U3RldmUgSw==?=
    Jun 10, 2004
  2. =?Utf-8?B?V2FyYW4=?=

    Auto-Suggested Textbox like google auto suggest

    =?Utf-8?B?V2FyYW4=?=, Apr 20, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    8,513
    inrakeshworld
    Jul 27, 2007
  3. linkswanted
    Replies:
    1
    Views:
    905
  4. rp
    Replies:
    1
    Views:
    520
    red floyd
    Nov 10, 2011
  5. Srijayanth Sridhar
    Replies:
    19
    Views:
    617
    David A. Black
    Jul 2, 2008
Loading...

Share This Page