The benefits of inside-out/flyweight objects have been beat to death on this board and center primarily on the stronger encapsulation of data and the orthogonality to potential property name clashes with super/subclasses. However, the approach needs a unique ID -- and, for reasons lost to history, someone used "$self" (hey, it's unique, right?) as cheaper than generating a unique ID and from there to just the memory address part, and the cargo cult followed.

I think the fundamental storage techinque is sound and using a UUID would fix up the refaddr problem -- though as I said, at the cost of coupling superclasses/subclasses more tightly. It's fine if everything in the class hierarchy is built the same way (e.g. on a blessed scalar with a UUID inside), but one loses the ability to subclass someone else's class (e.g. on CPAN) without caring what kind of blessed reference they used (hash, array, etc.) or whether it changes in some future version. For some, that may be a bigger benefit.

I'd still like to hear people's view on that topic -- whether that is important enough to justify the extra complexity of CLONE . I'd also like to get people's views on whether adding external dependencies on Data::UUID and/or Win32API::GUID are worthwhile or whether some other inline, pure-Perl"unique id" algorithm is preferable (with say, Time::HiRes, process ID, hostname/IP, etc.