Ah, I wasn't sure just what aspect of the code you were most interested in. A more traditional approach to inside out objects goes something like this:

use strict;
use warnings;
use Data::Dump;

package Counter;

my %data;

sub new {
    my ($class, $start) = @_;
    my $lu;
    my $self = bless \$lu, $class;

    $data{$lu = "$self"} = {count => $start};
    return $self;
}

sub add {
    my ($self, $value) = @_;
    $self = $data{$$self};

    $self->{count} += $value;
}

sub get {
    my ($self) = @_;
    $self = $data{$$self};

    return $self->{count};
}


package main;

my $ctr = Counter->new (7);
print "Start: " . $ctr->get () . "\n";
$ctr->add (3);
print "End: " . $ctr->get () . "\n";
[download]

which gains the data hiding without losing Perl's normal OO support.

The largest downside I see with the code you suggested is declaring all the anonymous subs in the constructor - that just doesn't scale well to anything other than toy code and is syntactically much nastier in my view.

Declaring the anonymous subs in the constructor may make sense to someone who has a lot of JavaScript experience. At that point it isn't really much different than thinking of the constructor as the class definition. Which can scale perfectly well as long as you are used to it, and have support for the other niceties that people expect from OO code. (Like some notion of inheritance and composition.)

... not sure if closed methods take up more memory with each instance...

They have to bind to the correct (and often unique) lexical environment, but that's about it.

not sure if closed methods take up more memory with each instance

There will be some table of pointers (a pad) so for captured and local lexicals. The opcode tree itself won't be duplicated.