joaquin@tid.es 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