With the release of Perl Best Practices, I looked at converting Math::Random::MT::Auto to using Class::Std instead of my own inside-out object support code. To my dismay, I found that Class::Std was not thread-safe. Further, its object structure (empty scalar ref) and single method of determining object IDs (refaddr) were incompatible with what I had written.
While I laud Damian Conway for the work he did on Class::Std, its slowness (due to calculating the object ID at every turn), lack of thread support, and inflexibilities (lack of support for user-supplied object ID, accessor naming conventions, and so on) lead me to further development of my inside-out support code. In overcoming these deficiencies, the resulting module architecture was such that it could not be combined with Class:Std, and thus required the issuance of an new and separate module to CPAN.
As part of the development of this module, I made sure that it incorporated all of the functionality of Class::Std so that there would be no want for using this module. Further, I discovered that, unlike hash-based objects, it was possible to share scalar-based objects between threads when using threads::shared.
Later, I was inspired by discussions on using arrays with inside-out objects. So I modified Object::InsideOut to allow the use of arrays (as well as hashes) for storing object field data.
I tested the performance of array-based Object::InsideOut objects on several platforms, and was impressed with the results: I got anywhere from 20% (Solaris) to 40% (ActivePerl) performance improvement for basic fetch and store operations over blessed-hash objects! Additionally, array-based objects consume less memory because Perl doesn't have to store hash keys for the object field data.
All in all, I feel that Object::InsideOut provides comprehensive support for the development of inside-out object classes that provides speed and flexibility, as well as a host of other capabilities including thread object sharing support.