in reply to A different OO approach
Let's look at the main problems with hash based objects that Abigail-II's inside-out objects solve:
- A sub-class can accidentally overwrite a super-class's attribute, by using the same hash key, without causing a compile time error.
- All attributes have global scope.
- Typing $self->{fo} when you meant to type $self->{foo} won't give you a compile time error.
- You can't inherit from classes implemented with non-hash references.
Unfortunately, you're class only solves the first one :-)
- oo_get/set allows you to get the attribute from any class through your optional third argument.
- Since attributes are still hash keys you can mis-spell an attribute name without any compile time errors.
- Having your own new() method makes mixing this into an existing class hard.
You could get much the same affect as your class by the traditional hash based approach, but adding another layer of indirection based on the class, e.g.:
{ package Foo; sub new { bless {}, shift; }; sub foo1 { my $self = shift; @_ ? $self->{+__PACKAGE__}->{foo} = shift : $self->{+__PACKAGE__}->{foo} }; }; { package FooBar; use base qw(Foo); sub foo2 { my $self = shift; @_ ? $self->{+__PACKAGE__}->{foo} = shift : $self->{+__PACKAGE__}->{foo} }; }; my $o = FooBar->new; $o->foo1("the foo from the base class"); $o->foo2("the foo from the sub-class"); print $o->foo1, "\n"; print $o->foo2, "\n"; # produces the foo from the base class the foo from the sub-class
... but you don't have to worry about the DESTROY method :-)
You also have the problems with overloading and re-blessing objects, but that's solvable like this.
It might be worth having another read of the first half of this node where Abigail-II talks, somewhat forcefully, about the strict/scoping issues :-)
I've got a base class that does some of the stuff that I think you're after... I'll spend a little time and clean it up enough to make public :-)