So:

• The number of objects stays the same
• The state stored by each object stays within it's class
• The state stored by each object remains the same. It's just stored in the class, rather than within the object.
• The method is used to implement data-hiding

Note we are not removing any duplicate state. We are moving state from the object to that objects class.

The motivation for doing it is data-hiding, not reducing duplicate state.

Actually I think it is very clear that the motivation is reducing the number of objects. I suppose data hiding might be a benefit but in general I don't respect data-hiding efforts in perl as valid activities. The idea is that instead of having one hash per object you now have a few larger structures per class but each object is only required to be a scalar.

I look at that and see Flyweight being applied to the perl structures. It's reducing redundant structures and in the process requiring less memory. It appears the typical application of FlyWeight (outside of Perl circles) is agnostic on language internals and intends to apply it to data and reduce memory load that way. This inside-out approach allows for a miminalist approach where you've got a few large arrays and a lot of small scalars instead of the more "normal" perl approach which simply has a lot of hashes. The assumption is that there is a higher memory overhead on having many hashes instead of few large arrays+many scalars.

Fun Fun Fun in the Fluffy Chair