Yeah, I thought about that. I figured that it more or less violated the flywieght pattern that Abigail was using...

I'm a little confused about why people keep referring to Abigail-II's object implementation as being based on the flyweight pattern.

According to my copy of Design Patterns a flyweight pattern is:

Using sharing to support large numbers of fine-grained objects efficiently

The example they use in the book is character objects in a word processor. Obviously having a separate object for each input character is going to have a huge resource overhead. So, instead, you create a single pool of objects - one per character - and use the same object for every instance of "a", etc.

Another example from my own experience in perl was when I worked on a project that had a large number of database tables that consisited of static data - lookup tables of info.

Rather than spend a lot of time doing a SELECT every time I needed the info I slurped up the entire table, made a pool of static objects, and served up the appropriate one on request.

To be useful flyweights can't have extrinsic state - no context dependant information - just intrinsic state.

So I can't see any relation between flyweights and inside out objects. Does the term mean something different in the perl world? If so - what, and why would accessing the hashes directly violate it?