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-28 06:53:08

----- Original Message ----- 
Joaquín Mª López Muñoz wrote

> "vicente.botet" ha escrito:

> > 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?
>
> This can be done by providing an interprocess-compatible holder, factory
> and locking policy. Tracking would not be affected. Instead of a custom 
> factory,
> we can also have an interprocess-compatible associative container
> and use it with the assoc_container_factory adaptor.
>
> I can try to put an example together in the examples section. However, I 
> don't
> know if this is a common enough need to promote it to lib status.

The example will be enough for me to probe the extension mechanisms.

> > Maybe this should be managed orthogonally but, can the current design 
> > manage
> > with persistent flyweights?
> > Which policies will we reused and which ones added?
>
> In this case, we'd need the factory itself be serializable. The rest of 
> policies
> wouldn't be affected, AFAICS.
>
> > If this is possible and natural, do you think that this could be 
> > included in
> > the list of future work?
>
> I can also try to provide an example for this. Whether the scenario has 
> some
> practical applicability, I don't really know, I'd love to hear from 
> potential users
> on this one.

I don't know if there are potentials users, but the fact we can do it 
reinforce the
credibility of the current design. So the example will be welcome.

> > 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.
>
> This is an interesting approach, transferring the more cumbersome syntax 
> to
> the core replacement case.Thanks for the suggestion!

You are welcome

> > I don't know if the Boost.Parameter library takes care of the exclusion
> > aspect?
> >
> > What do you think?
>
> This could be done with Boost.Parameter, yes.

I will take a look.

Thanks for all

---------------------------
Vicente Juan Botet Escriba