Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2012-05-24 20:29:25

Steven Watanabe-4 wrote
> 
> AMDG
> 
> On 05/23/2012 07:12 PM, lcaminiti wrote:
>> 
>> Hello Steven,
>> 
>> I quickly read the docs (see a couple of minor comments below). I'll
>> compile
>> and play with the examples this weekend.
>> 
>> I'm interested in the library. If you are looking for a Review Manager,
>> I'd
>> like to volunteer if that's OK with you and the Review Wizards.
>> 
> 
> It sounds good to me.  You're a library author,
> so I'm sure the Review Wizard will be okay with it.
> 
>> Minor Comments
>> 
>> 1) It'd be nice to have a motivating example up front (something not
>> trivial
>> but not as complex as the range formatter either).
>>
> 
> What about something based on any_printable?
> 
> typedef any<
>   mpl::vector<
>     copy_constructible<>,
>     typeid_<>,
>     ostreamable<> > > any_printable;
> 
> I believe that this has come up somewhere.
> ("Why can't I print boost::any to std::cout?")
> Is this about the level of complexity
> that you're thinking?
> 

Even somethings a bit more complex but printable is OK too. I will use the
lib in some use cases that I ran into the past and let you know if I find a
nice example not too complex (I don't remember what the use cases were but
they were about type erasure).

>> 2) Why placeholders _a, _b, ... instead of _1, _2, ...?
>> 
> 
> Because they represent named arguments, not
> positional arguments.  I used _1, _2, etc.
> in an earlier version of the library, and
> some people were confused about how they
> related to _1, _2 in Boost.Bind and Boost.MPL
> 

Got it. I missed that from the docs...

>> 3) I found the syntax of concept_interface difficult to understand... for
>> example, Base looks arbitrary. But then it's very nice to be able to
>> c.push_back(10) instead of call(...)
>> 
>> 4) Same for overloaded concept_interface where both Base and Enable look
>> arbitrary. (I wonder if macros could generate some of the boiler-plate
>> code
>> for the overload.)
>> 
> 
> Did you look at the doxygen/boostbook reference
> for concept_interface?  Is that sufficiently clear?
> 
> I realize that my descriptions in the examples
> are often a bit sparse.  Would something like
> this be clearer?  Do you think it's too verbose?
> 
> in custom.cpp:
>     This works, but we'd really like to call `c.push_back(10)`.
>     We can add members to __any by specializing __concept_interface.
>     The first argument is `push_back`, since we want to inject a member
>     into every __any that uses the `push_back` concept.  The second
> argument,
>     Base, is used by the library to chain multiple uses of
> __concept_interface
>     together.  We have to inherit from it publicly.  Other than
>     that we can ignore it.  The third argument is the placeholder
>     that represents this any.  If someone used `push_back<_c, _b>`,
>     we only want to insert a `push_back` member in the container,
>     not the value type.  Thus, the third argument is the container
>     placeholder.
> 
> in overload.cpp:
>     This uses SFINAE to detect whether a using declaration is
>     needed.  Note that the fourth argument of __concept_interface
>     is a dummy parameter which is always void and is
>     intended to be used for SFINAE.
> 

Maybe I used the wrong term in saying "arbitrary". I meant it looks
arbitrary to users because it essentially just exposes a library
implementation detail (but it's clear it's a "special" base that the lib
needs you to put there for the implementation to work). There is probably no
way for getting rid of Base, Enable, etc but to use macros. I think macros
would be a nice addition as an alternative to define concepts in your lib.
I'll see what macro syntax could be implemented (especially with variadic
macros, we can do a lot of nice stuff).

>> 5) There's a FIXME in the Reserved Identifier section.
>> 
> 
> Yeah.  I haven't come up with any scheme that
> covers all the identifiers I want to be able to
> use without being too broad.  I suppose I can
> always ignore the issue until problems surface
> like everyone else.
> 

Thanks.
--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/Formal-Review-Request-TypeErasure-tp4630373p4630477.html
Sent from the Boost - Dev mailing list archive at Nabble.com.