On 3/22/07, David Abrahams <dave@boost-consulting.com> wrote:
on Thu Mar 22 2007, Daniel Wallin <daniel-AT-boost-consulting.com> wrote:
David Abrahams wrote:
on Tue Mar 20 2007, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
These patches do not need to be applied in any particular order. Applying all three has the effect of making lazy binding behave more like the description in the documentation. I ran the Boost Parameter Library test suite and everything passed. Let me know if I've misunderstood something or if there's a better way to solve this problem or if you'd like additional documentation/tests.
I don't have any suggestions, though maybe Daniel W. does.
I think in general a better solution would be to add a member function to the keyword class template. Maybe:
template <class F> ... lazy(F const& f) {}
As a substitute for op|| ?
I would rather call it lazy_default.
However, I think the solution is in the lambda library already: http://boost.org/doc/html/lambda/le_in_details.html#lambda.unlambda
Really, users just need to provide a result_of compatible function object. So if the documentation says that more clearly and replaces the lambda example with a bind example, it would alleviate confusion. Unlambda gets rid of the operator|| overload resolution problem, but doesn't generate a lambda compatible functor as far as I know... at least not yet. For 1.34, since users can't use lambda anyway (due to lack of result_of compatibility) there's no need for this patch or renaming op||. In the future, if/when lambda is result_of compatible, keyword::operator|| will need to be renamed or somthing like this patch should be applied. My preference is to keep the current syntax. I kind of like using args[ _arg || default() ] better than args[ _arg.lazy(default()) ], especially if there's still args[ _arg | default() ].
And possibly change the docs to not use Boost.Lambda. We're going to hit the same problem with the every lambda library. Changing the implementation is to late for 1.34, but we should probably change the docs so they don't mention Lambda. The example would become:
bind(std::plus<std::string>(), ref(s1), ref(s2))
it's unfortunate, but not that bad IMO.
Is it better not to discuss lambda, or to mention unlambda as a way around this problem?
For 1.34, yes, I think it's better not to mention it. Daniel