Re: [boost] [type_erasure] Review started (July 18-27, 2012)

Subject: Re: [boost] [type_erasure] Review started (July 18-27, 2012)
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-07-27 14:14:03

Hi all,

Please find my review of Type Erasure below.

> Please state clearly whether you think this library should be accepted
> as a Boost library.

Yes.

> 1. What is your evaluation of the design?

The library is easy to use, at least for the use cases I am interested in.
Still it provides what I consider to be very very advanced features.

Though, I'd question the need for some those very advanced functionalities.
Will many people use something has cumbersome as :

tuple<requirements, _a, _b> t(&array[0], 2);
any<requirements, _a> x(get<0>(t) + get<1>(t));

I can't really evaluate if this has a huge cost in terms of complexity
in the code but I think the usages (i.e. the benefits) are likely to
be limited even among library developers. (By the way can this be
considered multi dispatch in C++ ?)

For instance, if removing this feature or simplifying the construction
would allow removing the possibility to construct a "reference any"
from a "reference-to-const any" I'd choose to remove the bug. Now, I
may be not knowledgeable enough to judge this point precisely. I think
I may limit the use cases of Type Erasure to "super interface" and
that there is more to it.

> 2. What is your evaluation of the implementation?

The implementation is nearly not documented. There are very few
comments in the private part of the code and there is no coding
guidelines. This makes a review of the implementation very hard
especially because a library like this is composed mostly of
boilerplate TMP code. I wanted to figure out how the vtable was
created and used, but I got discouraged. Adding some help for would be
hackers could be interesting.

Overall, the library has been submitted while still "young" (I am not
disregarding the many month of efforts that were likely put into
this). Steven mentions that he has not tried optimizing it yet. This
is a sound choice for a young library but I'd recommend it to be done
(and reviewed) before the library is released. We want to avoid a
"boost::function effect" : a different guy slapping the library for
being to slow and having a better design every 6 month. I think no one
so far reviewed the implementation so it won't hurt to have a second
round.

Another thing, would be to work on error messages, because this being
C++ they are horrible. I don't know if static asserts may help a lot
easily or not, but if anything can be done, it'll be welcome.

> 3. What is your evaluation of the documentation?

This is clearly the weak point of the library. The library offers a
new style of programming. One that deserves a proper step by step
tutorial. One that deserves a few guidelines.

Right now it's more or less backward. Very advanced concepts like
placeholder types jointly capture variables are introduced before
showing how to make your own concept and what's a concept by the way.

There are simple usages of Type Erasure that should be made more accessible.
I have been writing a sample tutorial that reflects how I would have
liked to learn what Type Erasure is about. Please find it attached. It
doesn't pretend to be complete or correct (it could use a serious
amount of re reading) but it shows what I believe to be a much more
natural progression.
Please excuse me for the ugly shell in a .txt but work happened. I had
no time for better.

Some other pieces of advice:
 - I'd rename "concept map" to "concept adapter". There's no map for
the user, it's your internal logic that is using one to find the
correct adapter for a given concept and type.
 - I'd rewrite the "Concept Definitions" page. You define 3 kinds of
high level concepts first, then explain what a primitive concept is.
I'd keep the placeholder stuff for a different section.

The good point is that the reference documentation looks complete and helpful.

> 4. What is your evaluation of the potential usefulness of the library?

It's huge.

While writing interfaces behaving similarly was somehow always
possible it was way too much of a pain to actually implement each time
and few people actually dived. Type Erasure does an excellent job at
streamlining the writing of interfaces. It has a good chance to become
as ubiquitous as the libraries it generalizes (any and function). It
may be too young to be a candidate for the next C++ standard update
but it feels more than adequate.

> 5. Did you try to use the library?  With what compiler?  Did you have
> any problems?

I used the library to write simple tests programs only. I used g++
(4.6) and clang (3.0) in both C++03 and C++11 modes. No problems
besides the fact that this is advanced C++ TMP and that the error
messages are as unfriendly as usual.

> 6. How much effort did you put into your evaluation?  A glance?  A
> quick reading?  In-depth study?

In-depth study.

> 7. Are you knowledgeable about the problem domain?

No I am not. I am just familiar with more traditional type erasure
having implemented a couple of type erased wrappers.

Many thanks to Steven for the library, it clearly offers new
perspective for C++.

Regards,

Julien