Re: [boost] [Review] Phoenix review starts today, September 21st

Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2008-10-01 09:17:15

Hartmut Kaiser wrote:
> Hi all,
> 
> Please always state in your review, whether you think the library should be
> accepted as a Boost library!
> 
> Additionally please consider giving feedback on the following general
> topics:
> 
> - What is your evaluation of the design?
> - What is your evaluation of the implementation?
> - What is your evaluation of the documentation?
> - What is your evaluation of the potential usefulness of the library?
> - Did you try to use the library?  With what compiler?  Did you have any
> problems?
> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
> - Are you knowledgeable about the problem domain?
> 
> Regards Hartmut
> Review Manager
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

I vote to accept Phoenix.

The only comments I have beyond the issues discussed by others:

- it would be nice to document which headers are required for the 
different types and facilities. Or did I miss this somewhere, the only 
#includes I remember were under the Constant References and Nothing headings

- comparison of compiler performance between BLL, Bind...
   (BLL compile times have a bad rap with my colleagues)

- discussion/example using with boost::function, boost::ref/cref,...

As others have mentioned, I'd like to see _1, _2, ... rather than the 
arg1, arg2... ala boost bind and reintroduce the FP background section 
in the docs.

I'm thinking the construct and new_ lazy functions will be particularly 
useful. Many of our classes end up in containers and or as output from 
transformed ranges, and end up with many bound static make functions 
replicating the constructor arguments. Phoenix "construct" makes all 
those "make"'s redundant. :)

Would it be generally useful to have a variant of "new_" that returns a 
shared_ptr directly? Without it one would need:

construct< shared_ptr<X> >( new_<X>( _1, 123, "another arg" ) )

maybe a second template parameter to new_ would allow:

new_<X, shared_ptr>(...)?

Jeff Flinn