|Do you know where your variables are?|
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?
In reply to Flyweights - different meaning in perl?