Some people consider being able to do this sort of thing bad. You cannot hide implementation details so you can change them without affecting other classes. With inside-out objects the hash can be lexically scoped to the class - so there is no way you can get at it from the super-class.

I'll get a compile time error with use strict because %Value isn't defined.

I know the code I showed didn't solve the problem. I wasn't trying to. I was demonstrating that you could get most of what your modules gives you using hash-based objects, rather than a global hash.

You can't inherit from classes implemented with non-hash references.

You can. You cannot implement non-hash objects using the OO module, but you can inherit from any object, because _your_ class' data is kept somehwere else. Anyways: the new() was in question. It's probably no good idea, although you're always allowed to override it.

If you read what I wrote again, you'll see I said:

Having your own new() method makes mixing this into an existing class hard.

Having a new function means that you have to take care with the order of your classes in the inheritence hierarchy, otherwise your new will override the new from the other class you are inheriting from.

won't work because it needs to be use base qw(Date::Simple OO) to get the correct new() method called. In general classes that you intend to mixin to existing class hierarchies should avoid constructors.

oo_get/set allows you to get the attribute from any class through your optional third argument.

Just as Perl gives you symbolic references. This is for example needed when you create accessor methods automatically.

Just because you can do it, doesn't mean that it's a good idea :-)
The fact that you cannot do this with Abigail-II's implementation of inside out objects as lexically scoped hashes is a feature, not a bug.

There are many other ways to make accessor methods without having the ability to get arbritary attributes from objects (e.g. with source filters or like this).

The idea of putting the data back into the object seperated by classes is great. It makes the object classically serializable and gets us rid of complicated DESTROY methods because it's all in one place. "Ay, there's the rob", it is then impossible to inherit from classes that don't use that new scheme.

Completely true. The point I was trying to make was that this was the only advantage your system gave you - while dropping the other advantages of using lexically scoped hashes:-)

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other