Re: [boost] [flyweight] key value with objects not constructible from a key

Subject: Re: [boost] [flyweight] key value with objects not constructible from a key
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2008-11-12 17:27:38

Michael Marcin <mike.marcin <at> gmail.com> writes:

> 
> Joaquin M Lopez Munoz wrote:
> > 
> > Then you can do something like this:
> > 
> >   struct texture
> >   {
> >     ...
> >   };
> > 
> >   texture load_from_texture(const std::string)
> >   {
> >     ...
> >   }
> > 
> >   struct loaded_texture:texture
> >   {
> >     loaded_texture(const std::string& str):
> >       texture(load_from_texture(str))
> >     {}
> >   };
> > 
> >   typedef flyweight<key_value<std::string,loaded_texture> >
> >   texture_flyweight;
> > 
> > Note that loaded_texture can be treated as an implementation
> > artifact: texture_flyweight is convertible to texture, which
> > is the type you're interested about.
> > 
> 
> But loaded_texture's can't share any state or be initialized with state 
> other than the key.
[...]

OK, then we're back to my original question: how do yo expect
the following statement to behave

  texture_flyweight fw("wood.texture");

when no previous equivalent flyweight object exists? Please
note that I'm not fooling around your problem, I understand
it but we have the crucial point that *all* the information
necessary to construct the value should be available at
the point of flyweight construction. This is not AFAICS a
particular limitation of Boost.Flyweight, but just the way
things are. This is why I'm inviting you to come up with
a suitable creation process (regardless of whether it is
implementable with B.F or not) so that I can see how you
expect the value construction information to be provided.
Just sketch how your ideal flyweight library should behave
under these circumstances and we'll see whether B.F is up to
the task or not.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo