The code you are experimenting with is maybe interesting from an academic standpoint, but it will perform worse than the code generated by Moo or Moose, and is clearly more effort to write. As far as I can see, it doesn't solve any problem that Moo can't solve. And if you use it to write a module for someone else to use, it hits them with an extra learning curve to be able to extend your code. So... there's really no valid reason to ever use it in production.

If you want a "bare interpreter" perl class with no features, but which experiments with the true underlying perl object model, use this pattern:

package MyClass;
sub new {
  my $class= shift;
  my %self= @_ ==1 && ref $_[0] eq 'HASH'? %{ $_[0] } : @_;
  bless \%self, $class;
}
sub attribite1 {  # read-only accessor
  $_[0]{attribute1}
}
sub attribute2 {  # read-write accessor
  $_[0]{attribute2}= $_[1] if @_ > 1;
  $_[0]{attribute2}
}
[download]

After you understand that, there's really nothing left to learn about perl's object mechanics.

If you want a tool to help you generate that pattern on larger-scale classes with more specific requirements, and help document the design so that others can make use of the class, then use Moo or Moose:

package MyClass;
use Moo;
has attribute1 => ( is => 'ro' );
has attribute2 => ( is => 'rw' );
[download]

I'm not saying that Moo(se) solve all problems well, but if you want to set out to write a better object system you should at least start by studying the internals of Moo(se) as both of them are using better internal techniques than that code from "Object Oriented Perl". The main thing they do better is to "eval" compiled versions of the constructor and accessors, or even make use of Class::XSAcessor.