in reply to Re: Preventing autovivification
in thread Preventing autovivification

In addition to this, you need to isolate the object (inside out) from the implementation (hash). In short, there is no way to stop an attribute from being added to a hash data structure. Auto-vivification is just part of the behavior of hashes.

You can achieve like-hashes that don't auto-vivify like this with Variable::Magic or Tie::HashRef, but I believe this to be outside the scope of the question.

With an inside hash, you would typically control autovivification with the set method.



Evan Carroll
The most respected person in the whole perl community.
www.evancarroll.com

Replies are listed 'Best First'.
Re^3: Preventing autovivification
by BrowserUk (Patriarch) on Feb 16, 2010 at 05:51 UTC
    In addition to this, you need to isolate the object (inside out) from the implementation (hash).

    Sorry, but I think you are compounding two different goals and coming up with a lemon.

    The original goals of IOOs were:

    • Proper encapsulation
    • Compile time checking of attribute use.
    • A technique not a module.
    • Don't depend on the implementation of the superclass.
    • Don't force a particular implementation on subclasses.
    • Simplicity.

    What you are suggesting is that the internal data implementation should be encapsulated (isolated) from the internal code. This was never a (stated) design goal, but can be achieved by the religious use of accessors, internally.

    In short, there is no way to stop an attribute from being added to a hash data structure. Auto-vivification is just part of the behavior of hashes.

    Actually, I think Hash::Util was specifically designed to address this.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom