Boost :

Date view	Thread view	Subject view	Author view

Subject: [boost] [type_erasure] Review report -- ACCEPTED
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-08-20 22:01:44

Next message: Cromwell Enage: "Re: [boost] Boost 1.51.0 released!"
Previous message: Marshall Clow: "[boost] Boost 1.51.0 released!"
Next in thread: Stewart, Robert: "Re: [boost] [type_erasure] Review report -- ACCEPTED"
Reply: Stewart, Robert: "Re: [boost] [type_erasure] Review report -- ACCEPTED"

Hello all,

Steven Watanabe's library Boost.TypeErasure is ACCEPTED into Boost.

SUMMARY

The library was reviewed from July 18 to August 3, 2012. There were 11
votes to accept the library and 2 votes to accept the library under
the condition of some modifications (at the end, these 2 votes were
essentially considered as "no" because there was no agreement on
implementing all the required modifications).

It was noted how the library offers non-intrusive and powerful
programming techniques that can be used in place of usual Object
Oriented (pure) virtual function interfaces (and with support for some
from of virtual "template" functions). The library can also be seen as
a generalization of existing Boost libraries like Any, Function, and
AnyIterator.

The library is accepted "as is", however most reviewers suggested to:
1) Dramatically ease the learning curve of the documentation by
providing a motivation section, step-by-step tutorial(s) to introduce
the basic features of the library, advanced topics section(s) to
introduced the additional features, an example section with
non-trivial use cases for the library, and additional examples to the
reference section.
2) Support down-casting.
While these changes are not a condition for the library acceptance, it
would be best if they were made part of the very first release of the
library.

A few reviewers found the name Type Erasure confusing, however others
did not. Alternative name were: Staged Typing, Deferred Typing, Type
Interface, Interface, Static Interface, Value Interface, Structural
Typing, Duck Typing, and Run-Time Concepts. There was some discussion
on the meaning of Type Erasure in Java and on its definition on wiki
(these should probably be both referenced in the documentation). The
current library name is considered acceptable and the final decision
on the library name is left entirely up to Steven.

DETAILS

Note that Steven might have already implemented some of the changes
listed below.

Features:
* Support down-casting. See [1], [10], and (4).
* Add macros for defining concepts. These macros could be added in
later revisions (they just provide a different syntax, no additional
functionality).
    ** From [10]:
        BOOST_CREATE_CONCEPT(container_concept, typename T,
                (void (push_back, T),
                 void (size))
        )
    ** From Steven:
        BOOST_TYPE_ERASURE_MEMBERS((push_back)(size)...)
        template<class V, class T = _self>
        struct container_concept : mpl::vector<
          has_push_back<void(const V&), T>,
          has_size<std::size_t(), const T>,
          ...>
        {};
* Add empty() to check if any holds a value or not. See [3] and [11].
* Add a built-in concept for unary plus +x (just pick a name for it). See (11).

Implementation:
* Can assertion enforce that same bindings are required for the
placeholders? See [13] and (3).
* Add assertion to check that in functions with multiple arguments the
underlining any types must match. See (7).
* Add in-code comments to the implementation (at least to
normalize.hpp). See [8] and [13].
* Can static assertions be used to improve error messages (see [8])?
Concept mismatch spew errors with internal implementation details, see
[10].
* Fix bugs:
    ** http://lists.boost.org/Archives/boost/2012/07/195367.php
    ** http://lists.boost.org/Archives/boost/2012/07/195396.php
    ** http://lists.boost.org/Archives/boost/2012/08/195662.php

Documentation:
* A few typos listed in [9].
* A draft on a proposed way to restructure the docs was offered in [8].
* Sean Parent's BoostCon 2012 "Value Semantics" could be used to write
a motivation section. See [9].
* Offer a comparison with usual OO (pure) virtual function interfaces.
See [1], [7], [8], and [9].
* Make sure all important elements document in the reference section
are also documented in a tutorial section (e.g., how the any
constructor binds placeholders, conversions,
BOOST_TYPE_ERASURE_MEMBER, concept_of, etc). See (1), (4), (6), and
[1].
* Clarify that references can be assigned but they cannot be rebound
to a different object. See (2).
* Clarify the rationale for using _a, _b, ... instead of _1, _2, ...
as soon as _a, _b, ... are first used (most users miss the "named vs.
positional parameter" rationale from the design decision section and
_1, _2, ... are such common constructs that many users will naturally
question the _a, _b, ... choice). See (5).
* Add an example section with non-trivial use cases of the library.
Consider to add the following examples:
    ** How to implement visitation, see (8).
    ** Model view controller, see [1].
    ** Run-time expression system (adding Concept = void
specialization), see [3].
    ** Multi-function, see [4].
    ** Printing, see (11) (note that Steven needed to answer too many
questions for Paul to be able to program this, ideally the docs would
have been clear enough for Paul to program this example without
Steven's help).
    ** Reference related work Adobe::Poly, see (13).
* Document all built-in concepts (possibly with a usage example for
each) and indicate which ones can be specialized. See [5], and [9].
* Add an example at the bottom of each reference page. See [11].
* Document that any(any<Concpet2, T2>, binding<Concept>) allows to
convert the vtable once and re-use it for all anys reducing run-time
cost. See [12].
* Consider a number of docs improvements as suggested in [13].
* Document the undefined behaviour pointed out in (12).
* Document limitations that some algorithms might encounter if they
need to access references and provide rationale of why references
cannot be handled differently (i.e., constructor flag and/or overhead
of managing vtable in dispatcher layer). See [12], and (14).

Many thanks to everyone that participated in the review!! I believe
Boost users will find this library useful.

The review manager,
--Lorenzo

On Sat, Aug 4, 2012 at 12:32 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
> Hello all,
>
> The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for
> my decision on the library.
>
> Thank you very much to Steven, everyone that submitted a review, and
> everyone that participated in the discussions.
>
> The review manager,
> --Lorenzo
>
> On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
>> Hello all,
>>
>> *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are
>> planning to submit a review, please do so by the end of today. ***
>>
>> Thank you to all that have participated to the review so far.
>>
>> The review manager,
>> --Lorenzo
>>
>> On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti_at_[hidden]> wrote:
>>>
>>> Hello all,
>>>
>>> After consulting the review wizards and Steven, I am extending
>>> Boost.TypeErasure review of one week, until August 3, 2012.
>>>
>>> Thank you to all that have submitted a review already and I am looking
>>> forward to receiving additional submissions.
>>>
>>> The review manager,
>>> --Lorenzo
>>>
>>> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti_at_[hidden]> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>
>>>> wrote:
>>>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti
>>>> > <lorcaminiti_at_[hidden]> wrote:
>>>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library
>>>> >> begins on July 18, 2012 and ends on July 27, 2012. ***
>>>> >
>>>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews
>>>> > :D ***
>>>>
>>>> *** Boost.TypeErasure review ends today July 27, 2012. If you are
>>>> planning to submit a review, please do so as soon as possible. ***
>>>>
>>>> Thank you to everyone who has commented on the library and submitted a
>>>> review so far!
>>>>
>>>> The review manager,
>>>> --Lorenzo
>>>> P.S. I am considering extending the review until end of day Sunday
>>>> July 29, 2012... I will keep you posted.
>>>>
>>>> > There have been interesting discussions on the library on the ML but I
>>>> > have not received any official review yet :( Especially if you are a
>>>> > user of Boost Any, Function, and Any Iterator, you definitely want to
>>>> > take a look at Type Erasure as it generalizes solutions provided by
>>>> > those other libraries.
>>>> >
>>>> > Thank you.
>>>> >
>>>> > The review manager.
>>>> > --Lorenzo
>>>> >
>>>> >> THE LIBRARY
>>>> >>
>>>> >> C++ provides runtime polymorphism through virtual functions. They are
>>>> >> a very useful feature, but they do have some limitations.
>>>> >> * They are intrusive. In generic programming, we can design an
>>>> >> interface which allows third-party types to be adapted to it.
>>>> >> * They require dynamic memory management. Of course, most of the
>>>> >> problems can be avoided by using an appropriate smart pointer type.
>>>> >> Even so, it still acts like a pointer rather than a value.
>>>> >> * Virtual functions' ability to apply multiple independent concepts to
>>>> >> a single object is limited.
>>>> >> The Boost.TypeErasure library solves these problems allowing us to
>>>> >> mirror static generic programming at runtime.
>>>> >>
>>>> >> Library source:
>>>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/
>>>> >>
>>>> >> Pre-built documentation:
>>>> >>
>>>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/
>>>> >>
>>>> >> You can also download archives with pre-built documentation from:
>>>> >> http://sourceforge.net/projects/steven-watanabe.u/files/
>>>> >>
>>>> >> YOUR REVIEW
>>>> >>
>>>> >> Please submit a review to the mailing-list by replying to this email
>>>> >> ("[boost] [type_erasure] Review ..." should be in the subject).
>>>> >>
>>>> >> Please state clearly whether you think this library should be accepted
>>>> >> as a Boost library.
>>>> >>
>>>> >> Other questions you may want to consider:
>>>> >> 1. What is your evaluation of the design?
>>>> >> 2. What is your evaluation of the implementation?
>>>> >> 3. What is your evaluation of the documentation?
>>>> >> 4. What is your evaluation of the potential usefulness of the library?
>>>> >> 5. Did you try to use the library? With what compiler? Did you have
>>>> >> any problems?
>>>> >> 6. How much effort did you put into your evaluation? A glance? A
>>>> >> quick reading? In-depth study?
>>>> >> 7. Are you knowledgeable about the problem domain?
>>>> >>
>>>> >> Thanks in advance to all who participate in the review discussion --
>>>> >> I'm looking forward to it!

Next message: Cromwell Enage: "Re: [boost] Boost 1.51.0 released!"
Previous message: Marshall Clow: "[boost] Boost 1.51.0 released!"
Next in thread: Stewart, Robert: "Re: [boost] [type_erasure] Review report -- ACCEPTED"
Reply: Stewart, Robert: "Re: [boost] [type_erasure] Review report -- ACCEPTED"

Date view	Thread view	Subject view	Author view

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk