Reputation: 6642
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
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