Boost logo

Boost :

Subject: Re: [boost] Case study: Boost.Local versus Boost.Phoenix
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-02-03 23:29:23


On 2/3/11 8:04 PM, Joel de Guzman wrote:
> You've just scratched the surface, and IMO, learned about the library in
> a way that I would not advice. To be honest, I never liked bind -- not a
> bit. If I did it my way, I'd write small modular phoenix functions
> just like you would in C++ or any FP language, but are fully curryable
> and lazy. It's very similar to what Local provides, albeit in C++ syntax
> instead of macros. By doing so, you avoid overly complex phoenix
> expressions
> and work closer to C++ but at the same time get all the benefits of FP.

As I said in my e-mail, I am sure the Phoenix is a wonderful tool after
you have taken a lot of time to learn how to use it, and hopefully I
will get the chance to become proficient at it myself one day. However,
not all of us want to go through a lot of learning effort just to be
able to conveniently create local functions. What is nice about
Boost.Local is that you only have to learn about a couple of relatively
simple concepts that have no dependence at all on the code that you want
to embed in the function, whereas for Phoenix you are limited in what
code you can include in the function until you have a great deal of
mastery over the library, and the error message will give you no help at
all in figuring out where you made a mistake so you need to have a lot
of patience.

Let me put this another way. Imagine that a new user comes along and
thinks, "Gee, I have this snippet of code that I'd like to pass to
another function inside a closure; does Boost have a library that makes
this easier for me than writing lots of boilerplate to define a function
object class?" If you say, "Sure! Check out the Phoenix library!" then
they will likely have an experience similar to mine, conclude that the
whole thing is more trouble than its worth, and go back to writing
function object classes. However, if you say, "Sure! Check out the
Local library!" then they will be much more likely to immediately see
how to use it to solve their problem and will adopt it after a
relatively shallow learning curve.

So to repeat my thesis: Phoenix is a great library, but unless
something significantly changes then I would strongly not recommend that
it be viewed as making the existence of Local redundant. If Local is
not included in Boost because theoretically Phoenix allows you to
accomplish the same thing then this won't cause the users who need it to
all learn how to use the theoretically nicer tool so much as it will
cause many of them to use no tool from Boost at all.

Local should be viewed as being complimentary to Phoenix rather
competing with it, and it should be evaluated on its own merits.

Cheers,
Greg


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk