Oesor
Oesor

Reputation: 6642

Using Moose to code objects in a polymorphic situation where clients expect to access $object->{private_variable} data

I know that while the internal representation of a Moose object is (rightfully) left undefined. However, in almost all cases, it's going to be a basic blessed hashref. In a situation where a new object is being created that may be called by legacy code that expects to access object attributes by grabbing it from the blessed hash ($object->{attribute}) as opposed to being encapsulated into the object by a method call ($object->attribute()), is there any way to explicitly define that the object needs to be stored as a blessed hashref in order for attributes to work properly?

Even better, are there any modules out there that decouple the blessed object being passed around from the object internal representation? It seems like it'd be possible to pass a tied hash around that could tie set defined hash keys into method calls against the instantiated metaobject so all the type checking still gets done even if some old code calls the object as $object->{attribute} = 'blahblah'.

Upvotes: 2

Views: 286

Answers (1)

Ashley
Ashley

Reputation: 4335

BEGIN {
    package MyMyMy;
    use Moose;
    has "watusi" =>
        is => "rw",
        isa => "Str";
}

my $mymymy = MyMyMy->new( watusi => "batusi" );
print $mymymy->watusi, $/;

$mymymy->watusi("woo-woo");
print $mymymy->{watusi}, $/;

$mymymy->{watusi} = "BAD DEV, BAD!";
print $mymymy->watusi, $/;

__END__    
batusi
woo-woo
BAD DEV, BAD!

I’m guessing you already knew that would work the way it does. I find it extremely difficult to imagine that Moose will ever change the internals in a way that would prevent that from working. So, as correct as you’re trying to be, if your real aim is just to get some legacy code out of the dump, I’d say you could rely on this provided there is a real plan to move forward and migrate to more modern practices and prevent the interface violations.

Upvotes: 1

Related Questions