Hi all, I don't see any comment during the review respect to the "Alternative/simpler configuration interface" originated by Peter Dimov. http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_n... Joaquin, you write in this section "An aim of Boost.Flyweight is to provide maximum customizability so as to meet everybody's needs from basic users to programmers with very specific requirements" I think that the proposal of Peter is more open, because there are less constraints in the template parameter. But even in this case the user needs factories, and the policy problem will now be reported on the factory class. The real problem is if the current interface reponds to the goal of the library. I'm not sure that the current policies are all orthogonal, and complete respect to the domain, I need more time to understand how all these policies interact between. For example, can the current design manage with interprocess flyweights? I'm thinking about the possibility to have flyweights fields in a multi_index stored on shared memeory, for example.Which policies will we reused and which ones added? If this is possible and natural, do you think that this could be included in the list of future work? Maybe this should be managed orthogonally but, can the current design manage with persistent flyweights? Which policies will we reused and which ones added? If this is possible and natural, do you think that this could be included in the list of future work? Joaquin I understand your concern, if we need to change the core then we recover only some lines of code of the flyweight class. So we can ask ourselfs why not to define a new class? Any way, let me purpose you an alternative witch do not suffer of "demands a slightly less terse syntax" // default configuration typedef flyweight<T> fw_t1; // change core implementation typedef flyweight<T, core<shared_ptr_core> > fw_t2; // or even with the deduced parameters, change core implementation typedef flyweight<T, shared_ptr_core > fw_t2; // change some aspect of the default core as now typedef flyweight<T, no_tracking > fw_t3; This will complicate only the flyweight class which needs to take care of the exclusion of the parameters. And of course this will need a description of what is expected from a core. I don't know if the Boost.Parameter library takes care of the exclusion aspect? What do you think? --------------------------- Vicente Juan Botet Escriba