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: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-11-12 15:48:24

joaquin_at_[hidden] wrote:
> Michael Marcin escribió:
> 
> Well, this terminology issue has been raised before and I finally 
> decided to stick with "factory"
> for lack of a more descriptive name. It is not an associative container, 
> though in most cases
> factories are built on top of associative containers. I hope the 
> important thing is that the reader
> gets a clear understanding of what these factories do in the context of 
> Boost.Flyweight.

I think the name is fine if the concept is extended to construct the 
values as well as store them.

> 
> Not sure if this is what you're after, but have you consulted the 
> section on key-value
> flyweights?
>

Yes

> 
> Does this approach your use case?
> 

Not quite.

Let's say my key is a filename and my value is a texture.

If texture has to be constructible from key then texture has to have 
direct access to file and image loading functionality. I can't pass any 
information other than the key to the construction site without 
resorting to singletons.

If factory handled the construction of texture I could have a custom 
factory which I passed a log, a filesystem, pluggable factory methods 
for handing additional image formats, etc.

I believe it also would allow for polymorphic flyweights. The factory 
could construct a derived type from the key and store reference to the 
base type.

-- 
Michael Marcin