Subject: Re: [boost] [type_erasure] Review started (July 18-27,2012)
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2012-07-26 05:57:05
Hi all,
here's my review for TypeErasure.
> Please state clearly whether you think this library should be accepted
> as a Boost library.
Let's answer this upfront: YES!
> Other questions you may want to consider:
> 1. What is your evaluation of the design?
Seen from outside, the design is clean and allows powerful constructs.
> 2. What is your evaluation of the implementation?
I only had a quick glance.
> 3. What is your evaluation of the documentation?
What is there is very good, but we could do with more documentation. A few
suggestions:
- provide a small example of usage of each concept to help new users manage
faster the learning curve.
I had some difficulties getting istreamable working and had to look at the
tests to finally get it.
- provide more real-looking examples of the sort of the polymorphic range
formatter. The more the better. I'll myself provide one later on in this
message.
> 4. What is your evaluation of the potential usefulness of the library?
Huge! And by this I mean a very interesting programming style which should
be made available also to average programmers.
Which makes the doc even more important.
> 5. Did you try to use the library? With what compiler? Did you have
> any problems?
Yes, on a real private project I do on my free time. I used VC9. I'm in
vacations so I couldn't try gcc and VC10 yet but I'll do this in the next
few weeks.
I got no problem besides a single warning about unused variable (fixed).
I tried the library for 2 different use cases:
- a streamable any (actually I need a boost-serializable any but didn't come
to it yet). One always needs something like this. In the past, I had to
modify a Boost.Any to achieve this. In my design, this helps implement my
low-level saving/loading to/from file easily as the low level layer needs no
knowledge about the types it gets, they're just a bunch of serializable
things.
- improve my MVC (Model-View-Controller) design. Here's my use case: I
started with a classical (OO style) interface-based design a graphical
editor where the user can place and edit items of different kinds on a
drawing area. The interface for these items is something along the lines:
struct IItem
{
...
virtual void createItem(...)=0; // creates in model
virtual void deleteItem(...)=0; // deletes from model
...
};
Different views dialogs however need some more concrete item types, like:
struct IType1 : public IItem
{
virtual void setName(...)=0;
virtual string const& getName() const = 0;
...
};
struct ISubType1 : public IType1
{
...
};
So far so good but then I want some classes which implement this. Where will
I implement these name members? In a class realizing IType1 (thus having to
redo it for ISubType1)? Or in a class which I also inherit from, in concrete
realizations of IType1 and ISubType1 (thus having either the dreaded diamond
or forwarding methods in all concrete classes)?
And here I have only one concept (naming) and a single type.
Get a few more of each and this will drain the life faster out of a C++
developer than a visit of a yearly vampire festival (unless you're also a
java developer, in which case you're already used to this :) ).
More seriously, the problem here is mixing interface definitions and
realizations. I changed IItem to an ItemConcept:
BOOST_TYPE_ERASURE_MEMBER((Controller)(has_createModelItem), createItem, 1);
BOOST_TYPE_ERASURE_MEMBER((Controller)(has_deleteModelItem), deleteItem, 1);
typedef ::boost::mpl::vector<
Controller::has_createItem<void(...)>,
Controller::has_deleteItem<void(...)>,
...
> ItemConcept;
typedef boost::type_erasure::any<ItemConcept> AnyItem;
I can even use composition to build my Type1Concept:
BOOST_TYPE_ERASURE_MEMBER((Controller)(has_setName), setName, 1);
BOOST_TYPE_ERASURE_MEMBER((Controller)(has_getName), getName, 0);
typedef ::boost::mpl::vector<
ItemConcept,
Controller::has_setName<void(...)>,
Controller::has_getName<...()>,
...
> Item1Concept;
typedef boost::type_erasure::any<Item1Concept> AnyItem1;
>From a user perspective, it is equivalent to use an IItem or an ItemConcept,
so that I now have a solution equivalent from the user's perspective, but
much better from the implementer's: I defined interfaces without paying any
dependency and I'm perfectly free to implement as I want, without fearing a
diamond or other ugly surprises.
While it was in front of my eyes, I realized the best part only yesterday.
Let's say my IItem would need a template method
struct IItem
{
...
// as before
virtual void createItem(...)=0; // creates in model
virtual void deleteItem(...)=0; // deletes from model
...
template <class T>
virtual void f (T& t); // will not compile
};
Sure, we all know this is not possible (sigh) . However, if I postulate that
I require T to be foo-able for all realizations of this interface, meaning I
can implement f as:
t.foo();
It is anyway good style to document the template parameter's requirements
anyway, so this bears no cost.
Ok, then I can use an any<fooable> in my concept
typedef ::boost::mpl::vector<
Controller::has_createItem<void(...)>,
Controller::has_deleteItem<void(...)>,
Controller::has_f_able<void(any<fooable>&)>,
...
> ItemConcept;
This is really close from virtual template methods.
There is only one thing missing to be able to throw away all these
interfaces: the ability to navigate through dynamic/static cast in the
hierarchy. TypeErasure supports upcasting of concepts but not downcasting.
According to Steven, this would be possible.
I won't make it an acceptance condition, but I could make good use of this
feature. My use case: different view items get an IItem, then a view Item
for Type1 would safely cast down its IItem to IType1. This is at the moment
not possible with TypeErasure. I view this as a killer feature, so I can
only advise providing it at a later point.
One last request: I would like the possibility to read the concept of an any
through a metaprogram. I found this:
/** INTERNAL ONLY */
typedef Concept _boost_type_erasure_concept_type;
I try to avoid using internals, could this be made part of the public
interface?
Use case:
My view item for Type1 gets an any<Type1Concept> and needs a property page
for it. Obviously it would need name setting/showing, which other
any<ItemConcept> would not. The property page dialog could, with a simple
template function, get the concepts supported by an any and build the dialog
accordingly. I would thus be able to write a single generic dialog class for
all types.
> 6. How much effort did you put into your evaluation? A glance? A
> quick reading? In-depth study?
About 10-15 hours trying on real, not toy code.
> 7. Are you knowledgeable about the problem domain?
I've used Boost.Any/Function several years and made my own serializable any.
I want to thank Steven for providing this great library, which I will use in
any case, accepted or not.
Thanks Lorenzo for managing the review and getting it scheduled so fast.
Christophe