gmane.comp.lib.boost.announce

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

Hi all,

The formal review of Flyweight library started January 21 and will end 
January 30, we have a few nice reviews, but I'm sure that those who 
haven't reviewed it are also interested in the library . The library 
solves quite a common programming pattern, is small and very well 
documented. So don't be afraid to try it! Information for reviewers:

*Description:*

Flyweights are small-sized handle classes granting constant access to
shared common data, thus allowing for the management of large amounts of
entities within reasonable memory limits. Boost.Flyweight makes it easy
to use this common programming idiom by providing the class template
flyweight<T>, which acts as a drop-in replacement for const T.

*Online docs:*

http://tinyurl.com/2sstyr
http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html

*Download:*

http://tinyurl.com/hrdm6
http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directory=Patterns

*Notes:*

1) We've seen some suggestions in the mailing list for Flyweight.
Joaquín has nicely explained a couple of issues that we'd like to

(Continue reading)

headers

Pavel Vozenilek | 30 Jan 02:57

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

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.

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.

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.

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

(Continue reading)

headers

Joaquín Mª López Muñoz | 31 Jan 17:36

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

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

(Continue reading)

headers

vicente.botet | 3 Feb 11:59

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

Hi all,

Thank you very much Joaquín , I have learn a lot with your library
and the review. Thanks also for all the pertinent answers.

Thanks for extending the review period.

Ion Gaztañaga wrote:
> The formal review of Flyweight library, proposed by Joaquín M. López
> Muñoz, begins today (sorry for the late announcement):
> * What is your evaluation of the design?

The library has a simple to use interface based on a understandable
domain-specific language having a good configurability and extensibility
degree, even if the naming of some policies could  be improved.

This easy to use interface hides a more complex design. The relations
between the different policies are not evident, and even if the library
provides a elegant way to extend it, it's no evident to define such
extensions without reading the code. Maybe the documentation should
include a deeper description of the collaboration of the core implementation
and the different policies.

I like the way Boost.Parameter is used. In particular the use of is_locking,
is_tracking, ...  specialization in order to declare extensions.

I like the idea to encapsulate in flyweight<T> the acquisition and the
release of the shared resources, and as consequence masking the factory
initialization.

(Continue reading)

headers

JOAQUIN LOPEZ MU?Z | 3 Feb 23:52

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

----- Mensaje original -----
De: "vicente.botet" <vicente.botet <at> wanadoo.fr>
Fecha: Domingo, Febrero 3, 2008 12:00 pm
Asunto: Re: [boost] [review] Review of Flyweight library started 
January 21 and still running!
Para: boost <at> lists.boost.org

> Hi all,
> 
> Thank you very much Joaquín , I have learn a lot with your library
> and the review. Thanks also for all the pertinent answers.

You're welcome. Thank you for taking the effort to do such a
thorough review.

[...]
> > * What is your evaluation of the design?
> 
> The library has a simple to use interface based on a understandable
> domain-specific language having a good configurability and 
> extensibilitydegree, even if the naming of some policies could  be 
> improved.
> This easy to use interface hides a more complex design. The relations
> between the different policies are not evident, and even if the 
> libraryprovides a elegant way to extend it, it's no evident to 
> define such extensions without reading the code. Maybe the
> documentation should include a deeper description of the
> collaboration of the core implementation and the different policies.

Point taken. Will try to improve that part.

(Continue reading)