Here's a Dog class which admits dynamic strong typing/value types, like I suggested in my replies to xdg and TimToady.

package Dog;

use Tie::Constrained;
use Scalar::Util qw/blessed/;

# constraint object
my $is_a_dog = Tie::Constrained->new(
    sub { blessed $_[0] and $_[0]->isa('Dog') },
);

sub new {
    bless {}, shift;
}

# not a constructor this time, ties the referent
sub MODIFY_SCALAR_ATTRIBUTES {
    my $class = shift;
    my $ref   = shift;

    tie $$ref, 'Tie::Constrained', $is_a_dog;

    # ignore attributes for this example, but
    # must have one to get called
    ();
}

sub bark {
    my $self = shift;
    print "Woof!\n";
}

package Cat;

sub new {
    bless {}, shift;
}

package main;

my Dog $spot : Generic ;

eval {$spot->bark}
    or warn q(Only tangible Dogs bark, ), $@;
eval {$spot = Cat->new}
    or warn q(Can't be a Cat, ), $@;
eval {$spot = Dog->new}
    or warn q(Major malfunction: ), $@;
eval {$spot->bark}
    or warn q(Only tangible Dogs bark, ), $@;
[download]

Which prints,

Only tangible Dogs bark, Can't call method "bark" on an undefined value at dog.pl line 42.
Can't be a Cat, Constraint violation: at dog.pl line 44
Woof!

Declared attributes would likely be stored in %{tied($spot)}, which is persistent and independent of whatever is assigned the name. Matching declared attributes with Dog instance ones could be part of the constraint.

This is a very rough proof of concept. I haven't tried to make my $spot : Watchful = Dog->new; do the right thing. I haven't checked if it plays nice with fields.pm or Attribute::Handlers. I'd be surprised if it did at this stage.