| Subject: | Consider gut-wrenching support for e.g. unit tests |
Under normal conditions it's fine that object slots are private to the class.
However, it's also quite normal around Perl to gut-wrench into the insides of an object during special cases like unit tests. A t/01someclass.t is usually considered tightly coupled enough to Some/Class.pm that direct hash key access isn't considered too bad. Such techniques as
{
local $obj->{somekey} = "some temporary value";
is( $obj->amethod, "expected result" );
}
are common.
Object::Pad's :repr(native) slot representation does not allow this kind of thing.
Possible ideas around it:
1) A flag to force :repr(HASH) on all otherwise-native classes, so the unit test can peer inside the object, though that still leaves the question of how it determines slot index numbers:
BEGIN { $Object::Pad::FORCE_HASH_REPR = 1; }
use Some::Class;
my $obj = Some::Class->new;
{
local $obj->{'Object::Pad/slots'}[4] = "a temporary value";
...
}
2) Provide a utility function to allow runtime access to named slots. `local` doesn't work with lvalue-returning functions, but Syntax::Keyword::Dynamically would. Or users can just assign without local, and assign back afterwards:
use Object::Pad qw( slotsv );
use Some::Class;
my $obj = Some::Class->new;
{
my $old = slotsv($obj, '$somekey');
slotsv($obj, '$somekey') = "a temporary value";
...
slotsv($obj, '$somekey') = $old;
}
--
Paul Evans