Re: [boost] [review] Review of Flyweight library started January 21 and still running!

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2008-01-31 11:36:56

Hello Pavel, thank you for participating in the review! Excuse
my late answering, I've been through a couple of hectic days.

Pavel Vozenilek ha escrito:

> This is not a review of the library, rather a wish list.
> (I started to read it only now.)
>
> 1. (Not important) I personally would like
>    a different name: "const_singleton" so.

Singleton? I don't see how that pattern is related to the flyweight lib.

> 2. There should be macro BOOST_FLYWEIGHT_NOT_USED
>     which would disable functionality of the library
>     so that flyweight<std::string> would become std::string
>     - for troubleshooting and performance tests.
>
>    An ability to disable flyweightness per type or tag would be useful.

Won't it suffice for the user to conditionally typedef her type to
flyweight<X> or X depending on some macro of her own? How
would a lib-provided facility help more than that?

> 3. More support for troubleshooting. I would like to see
>     something as macro BOOST_FLYWEIGHT_PARANOIC_MODE
>     where each factory instantiates 2 objects with the same value
>     and the holder returns one or the other, alternating them
>     over and over where possible.
>
>     This should help to detect wrong use of the flyweight.

Could you please elaborate. I'm not getting what your inteded usage
scenario is. Do you mean duplicating each flyweight value or the
factory itself, an to what purpose?

[Incidentally, I think you're meaning "factory" instead of "holder",
admittedly the terminology can be a bit confusing.]

> 4. Support for unit tests run within application session.
>      I would like to see something as:
>
> TEST()
> {
>     ToolThatRevertsHolderOnBlockExitToStateAsNow<std::string>  aux;
>
>      ... use flyweight, e.g. create zillion different values in a stress
> test
> }

I don't think that ToolThatReverts... can be sensibly implemented, because
of this: For each value in the factory, there are n (with n>=0) flyweight
objects pointing to it. I can restore the value, but not the flyweight objects,
that live their seprate lives in whatever external context they've been
constructed. So, the only thing a factory could do would be to restore
values without external references (which can exist only if using the
no_tracking policy).

> Possibly an ability to temporarily preserve current instances
> owned by the specified holder, make the holder emply and
> on exit from the unit test restore the initial state.
>
> Ideally, I should have a way to do this with _all_ flyweight holders
> in the applications, w/o need to specify them explicitly.
>
> 5. (This is a biggie) Ability for the end user to specify somewhere
>     the set of allowed shared values created by the factory,
>     by enumeration or with a constraint on those values
>     (only the surnames "Smith", "Jones", "Jackson" and those starting with
>     "Mc") so all other values would be created and used as nonshared.
>
>     The effects would  be:
>     * reduction of the possible unlimited growth of the stored instances,
>     * locking and reference counting overhead  for values too hard
>       to share would be eliminated.

In principle, a factory adaptor could be done to implement this behavior,
with the only caveat that this interferes with the equality semantics issue
we've been discussing some days ago. Also, I'm not convinced this
would gain any kind of performance, reference counting is almost always
cheaper than copying a heavy object like those expected to be
flyweighted.
Let me put this on my list of things to study.

> 6. An API (possibly just in debug mode) which provides usage statistics
>     for a flyweighted type (where available).

Yes, this I'll be able to address as part of the future introspection API.

> 7. For people who learn from examples: the more of them the better.

I've got it in my todo list to keep adding examples. Specific proposals
welcome.

>     The documentation could have a section about potential
>     disadvantages of flyweights.

This will nicely fit in a future performance section that I committed to write.

> /Pavel

Best,

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