Re: [boost] [flyweight] Review period extended to February 3

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-02-04 11:08:57

On Feb 3, 2008 6:20 PM, "JOAQUIN LOPEZ MU?Z" <joaquin_at_[hidden]> wrote:
> ----- Mensaje original -----
> De: Alberto Ganesh Barbati <AlbertoBarbati_at_[hidden]>
> Fecha: Domingo, Febrero 3, 2008 12:39 pm
> Asunto: Re: [boost] [flyweight] Review period extended to February 3
> Para: boost_at_[hidden]
>
> > 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