[Proto] Review result
Hi all, initially I was hoping to find some time over the last weekend to go through the reviews in great detail to put together a proper review report. Well, as things happen, I was not able to find the time :-( To avoid further delays, here is the short version of the review result: Proto got 16 reviews (That's well above average! Thanks to all for participating), out of which 15 have been positive. The one 'No' essentially stated that the library, even if doubtless very useful, shouldn't be accepted yet, mainly because there has to be done more work in the area of formalizing the problem domain. In my opinion this is an overwhelming result and I'm whole heartily agreeing with the majority of the voters. Proto is accepted as a Boost library. The discussions have been very detailed and there have been raised a lot of (mostly minor) issues, but Eric is aware of the problems and is working on solving them. I'll try to put together a summary as soon as possible. Regards Hartmut Review Manager
Hartmut Kaiser wrote:
Hi all,
initially I was hoping to find some time over the last weekend to go through the reviews in great detail to put together a proper review report. Well, as things happen, I was not able to find the time :-(
To avoid further delays, here is the short version of the review result: Proto got 16 reviews (That's well above average! Thanks to all for participating), out of which 15 have been positive. The one 'No' essentially stated that the library, even if doubtless very useful, shouldn't be accepted yet, mainly because there has to be done more work in the area of formalizing the problem domain.
In my opinion this is an overwhelming result and I'm whole heartily agreeing with the majority of the voters.
Proto is accepted as a Boost library.
The discussions have been very detailed and there have been raised a lot of (mostly minor) issues, but Eric is aware of the problems and is working on solving them. I'll try to put together a summary as soon as possible.
Thanks to everybody who participated in the review, esp. Hartmut for being review manager. For anybody interested in following along, branches/proto/v4 is where I'm incorporating the review feedback. It already has all of the interface breaking changes I plan to make, modulo any necessary changes that come out of the "boost::result_of and C++03" thread. I'll be trying very hard to get proto into trunk in time for 1.36. Thanks again, -- Eric Niebler Boost Consulting www.boost-consulting.com
On 04/07/08 17:04, Hartmut Kaiser wrote: [snip]
participating), out of which 15 have been positive. The one 'No' essentially stated that the library, even if doubtless very useful, shouldn't be accepted yet, mainly because there has to be done more work in the area of formalizing the problem domain.
There was also an issue with separation of transforms from grammars. This mixing made it hard for me to understand transforms. I believe separating the two would make understanding for other novice users easier also. Of course I'm not even real sure that separation is possible, as I intimated with the '*highly* speculative' qualifier in my review. However, since then I've been trying to separate the two. This lead me to understand *maybe* why bundling the two is necessary. The pass_through transform docs contain: , boost::result_of < Grammar::proto_childN(Expr::proto_childN, State, Data) >::type Now if Grammar::proto_childN is *not* derived from pass_through, then that would make the above an object CTOR call. Unless the N-th child has a 3 element CTOR, then this will fail to compile. OTOH, if then N-th child is derived from pass_through (IOW, if the grammar and transform are bundled), then this will compile. Eric, is that about right?
Larry Evans wrote:
There was also an issue with separation of transforms from grammars. This mixing made it hard for me to understand transforms. I believe separating the two would make understanding for other novice users easier also. Of course I'm not even real sure that separation is possible, as I intimated with the '*highly* speculative' qualifier in my review. However, since then I've been trying to separate the two. This lead me to understand *maybe* why bundling the two is necessary. The pass_through transform docs contain:
, boost::result_of < Grammar::proto_childN(Expr::proto_childN, State, Data) >::type
Now if Grammar::proto_childN is *not* derived from pass_through, then that would make the above an object CTOR call.
No, you are confusing how boost::result_of and proto::when interpret function types. result_of has a protocol, documented in TR1, for calculating the return type of a function or function object given a function type as above. proto::when has a different convention, which doesn't come into play here.
Unless the N-th child has a 3 element CTOR, then this will fail to compile. OTOH, if then N-th child is derived from pass_through (IOW, if the grammar and transform are bundled), then this will compile.
Eric, is that about right?
-- Eric Niebler Boost Consulting www.boost-consulting.com
participants (3)
-
Eric Niebler -
Hartmut Kaiser -
Larry Evans