Re^2: Preventing autovivification

[EvanCarroll]

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.

[BrowserUk]

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.