I have already posted an idea in the disucussion, but this already has developed and here comes the result:

package OO;
use strict;
use warnings;
use Carp qw/croak/;
[download]

This is the first question: the name, how should that superclass be called? 'OO' is just a thought and probably no too good idea.

#--------------------------------------------------------------------
#       The registry itself: storing all the data of your objects
#--------------------------------------------------------------------

my %Object = ();

# Object => Class => Attribute
[download]

This is not a question, but the idea: Store all the information right here in that lexical. A question is the structure: Class,Field,Object, which would more directly inherit Abigail's idea or Object,Class,Field, which has the advantage that the destruction can be done easily without tricks or search.

#--------------------------------------------------------------------
#       inheritable constructor with generalized behaviour
#--------------------------------------------------------------------
sub new {
        my $class = shift;

        my $self = bless [caller], $class;

        # is that neccessary if you can override new()?

        if( $self->can( 'initialize' ) ){
                $self->initialize( @_ );
        }

        return $self;
}
[download]

Should there be something like this constructor at all? You see, it is quite unneccessary, but what else should a constructor do and why should every class write something similar?

#--------------------------------------------------------------------
#       Use these two methods to get and set members of your
#       object and they will do encapsulation for you
#
#       BE CONSISTENT our your OO will BREAK!
#
#--------------------------------------------------------------------
sub oo_get {
        my $obj   = shift;
        my $field = shift;

        # member hash is based on caller class
        #  and may be overwritten by third argument to get()

        my $class = @_ ? shift : caller;

        $Object{ $obj }{ $class }{ $field }
}
sub oo_set {
        my $obj   = shift;
        my $field = shift;
        my $value = shift;

        my $class = @_ ? shift : caller;

        $Object{ $obj }{ $class }{ $field } = $value;
}
[download]

These two are the crucial point of the whole thing: They get/store attribute data depending on the caller. What? Yes. These two are not to be used anywhere except in the package that defines a class. This way each class has it's own data slot as the idea is.

The names of these two must be carefully chosen, but probably 'oo_' can be avoided by classes easily.

#--------------------------------------------------------------------
#       most important: DESTROY
#--------------------------------------------------------------------
sub DESTROY {
        my $obj = shift;

        delete $Object{ $obj } #that's why the structure of the regist
+ry was chosen like that
}
[download]

Jep, that's all about the possible memory leaks. Object deletion causes object data deletion. by having this in the superclass, you needn't rewrite it in every class.

#--------------------------------------------------------------------
#       create_accessor class method to create simple accessor/mutator
+ methods
#--------------------------------------------------------------------
sub oo_create_accessor {
        my $pkg = shift;

        no strict 'refs'; # we're messing around with the symbol table

        foreach my $mem ( @_ ){

                my $symbol = $pkg . '::' . $mem;

                if( defined *{ $symbol } ){
                        croak "Attempt to redefine $symbol via create_
+accessor";
                }
                else {
                        *{ $symbol } = sub {
                                my $self = shift;

                                if( @_ ){
                                        $self->oo_set( $mem , $_[0] , 
+$pkg );
                                }
                                else {
                                        $self->oo_get( $mem , $pkg );
                                }
                        };
                }
        }
}
[download]

This is clear and is subject to be made more advanced but shows that it's easy to create accessor/mutator methods ala MethodMaker.

#--------------------------------------------------------------------
#       debugging function/method (as you like it)
#--------------------------------------------------------------------
sub oo_registry {
        return \%Object
}

1;
[download]

further steps

Now one can write a serialization/deserialization method in that class. The stringification thing can be helped out using overload::StrVal as proposed by adrianh.

I hope this RFC is an inspiration to some as Abigail's post was inspiration to me.