|Keep It Simple, Stupid|
No apology necessary. As far as I am aware you were simply passing on the example given in the Design Patterns book you mentioned. That in turn was quite possibly re-telling an example from an intermediary going all the way back to the article I found. I haven't located any early references to the term "Flyweight objects". Maybe there were many itermediaries between the original example and the version in the book, and like the child's game of chinese wispers, the example becomes slightly distorted with each retelling. By the time I read your description, and coming to it from the perspective that I didn't understand the term and trying to associate it with Abigail's Inside-Out objects, I simply got confused.
I understand what you (they) mean about patterns, but again, applying the label "Design Patterns" suggests that it is a new discovery where I would see it as a re-recognition of a long know phenomena summed up previously by such adages as "There's nothing new on earth" or even "History repeats itself".
The first time I recall encountering something that was similar was whilst working on the functional verification program for Presentation Manager, the GUI of OS/2. One of our early tasks was to write test programs to exercise as many aspects of that GUI as possible. However, the only documentation available was a 6 inch thick stack, of 132 column green and white lined, fanfold listing paper known colloquially as "the brick", but officially as "The Specification Document". This was the most amazing mix of high and low level design work ranging from what fore/background color schemes worked best, down to the bits and bytes of the algorithms used to minimise redrawing of overlapping windows, and pseudo code descriptions (that changed almost daily) of the API's. From this document and twice weekly builds almagamated from development teams spread across 4 continents and the full 24 hours of timezones, we were expected to put together applications that could be verified and then used a regression tests.
One of the guys decided to put together a simple, mini-spreadsheet program. Reading the spec he noted that each window could have one or more user-defined window words associated with it. These seemed like an ideal place to store the cell values, formulea, formatting information etc as you could then write a generic window procedure that each time any event (mouse click, keystroke etc.) occured in any window of that class, the window procedure was called in the context of the window generating the event. It was then a simple call to access the window words (instance data) for the cell of the spreadsheet the user was intereacting with. Whilst the spreadsheet was a being written, it had a 4 x 4 grid of cells and seemed to work fine. However, once he tried to scale this up to 26 wide by 255 deep, it fell in a heap.
Not surprising really as the system only had 4k window handles available and this one application was trying to allocate around 6k of them!
The simple expedient of moving the spreadsheet data into a 2d array, indexed by the (x,y) coordinates of the cell. This meant that the cell data could be accessed by a simple translation of the position of the click in the main window. Passing that data to a single, Cell-class window that got positioned relative to the click, meant that with changing about 10 lines of code, the spreadsheet could handle a grid of 676x1024 easily on a state-of-the-art machine which at that time had a 16 MHz processor and 4MB of ram! Fun times.
Examine what is said, not who speaks.
In reply to Re: Re: Re: Re^4: Flyweights - different meaning in perl?