Re: Preventing autovivification

You should not be returning a hashref from your get() method. It completely negates the purpose of using InsideOut objects.

Try this:

package InOutObj;

use strict;
use warnings;
use Scalar::Util qw( refaddr );
{
    my( %upper, %lower );

    sub new {
        return bless \do{ my $dummy }, shift;
    }

    sub getUpper {
        my $self = shift;

        return $upper{ refaddr $self };
    }

    sub getLower {
        my $self = shift;

        return $lower{ refaddr $self };
    }

    sub set {
        my ( $self, $arg ) = @_;

        $upper{ refaddr $self } = uc $arg;
        $lower{ refaddr $self } = lc $arg;
        return;
    }

    sub DESTROY {
        my $self = shift;

        delete $upper{ refaddr $self };
        delete $lower{ refaddr $self };
        return;
    }
}

1;

package main;

use strict;
use warnings;

my $obj = new InOutObj;

$obj->set('i LiKe WiNe');

# User should not be able to make up stuff on their own!
print $obj->getUpper . "\n";
print $obj->getLower . "\n";
[download]

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.

"I'd rather go naked than blow up my ass"

Comment on Re: Preventing autovivification Download Code

Replies are listed 'Best First'.
Re^2: Preventing autovivification by Just in (Sexton) on Feb 16, 2010 at 04:44 UTC
"You should not be returning a hashref from your get() method. It completely negates the purpose of using InsideOut objects" Thanks. That's a clear cut rule I can work with and remember. I went off at a tangent w.r.t. DC's PBP 1st ed. @ p345	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: Preventing autovivification by EvanCarroll (Chaplain) on Feb 16, 2010 at 04:43 UTC
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	[reply]
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. "I'd rather go naked than blow up my ass"	[reply]