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

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2008-01-28 04:40:34

"vicente.botet" ha escrito:

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

Correct. More open here does not necessarily mean more powerful --we simply
charge the user with more work to do. The question is whether the current
policy decomposition is good enough so as to not need a blanket variation such
as Peter's proposal.

> 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?

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.

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

> 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!

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

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo