Re: [boost] [review] Review of Flyweight library started January 21 and still running!: Alternative/simpler configuration interface

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-01-27 18:03:55

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_notes.html

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