Re^2: Preventing autovivification

[EvanCarroll]

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.