On Feb 3, 2008 6:20 PM, "JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote:
----- Mensaje original ----- De: Alberto Ganesh Barbati <AlbertoBarbati@libero.it> Fecha: Domingo, Febrero 3, 2008 12:39 pm Asunto: Re: [boost] [flyweight] Review period extended to February 3 Para: boost@lists.boost.org
JOAQUIN LOPEZ MU?Z ha scritto: [...]
I am not plainly denying the existence of sensible K-->T scenarios, but I thought long and hard and couldn't find any. If you can come up with one I'll be happy to know. So, my analysis led me to conclude that the right approach is to assume that K==T, that is, the set approach, or at most than K and T are just different representations of the same information.
One such scenario is right there in the GoF book, the word- processing application that uses one flyweight object for each glyph in the document. I have another case in an project I am working on: in a 3D application, I have heavyweight 3D mesh objects that might be shared among several actors. The key of a 3D mesh is just its filename. I don't want to load an entire mesh into memory just to find out that I have it already. Yes, I could delay the actual loading of the mesh until the first time it is actually used, but that would be impractical for at least two reasons: 1) any error encountered while loading the mesh would occur in the wrong place and couldn't be handled properly, 2) the place where the mesh is used is inside a tight rendering loop with strict real-time requirements which can't be blocked by costly I/O operations.
OK, I'd classify these two examples as scenarios where K and T contain esentially the same info but the translation function f() is computationally expensive. This is a valid context, just not the one I deem the most common.
Just to chime in here, that is also my use case, and I add textures (images) to that mix. I usually have a flyweight factory that holds large 3D meshes, and another one that holds textures. Lookup is done based on name, and construction requires loading a file from disk. FWIW, all of my flyweight implementations have been key based (the map/set problem you spoke of), but I often wished for a set-based implementation too. I think offering both would be the correct way forward. --Michael Fawcett