Roland Bock wrote: Hi Roland, It's unfortunate that there are two lists where the review is taking place. Most of the issues you mention below are already discussed in the boost.devel list. I would urge you to see the history of the review that has transpired so far. I'm CC'ing the Boost.Devel list.
Name: ====== Personally, I think, that the naming of libraries is not just a minor issue. The name of a library not only helps potential users to find it. It also helps the library's developers and contributors to focus. With a name like Phoenix, the sky is the limit. Remember the time when Firefox aka Mozilla was called Phoenix?
The same is true for Spirit. If nobody had told me to use Spirit for parsing, I probably would never have come to use it. And looking at Spirit, I was quite astonished to find the Phoenix things in there.
To me Spirit looked like small collection of libraries inside a bigger collection of libraries (boost). I bet that there would have been quite a different development with a different, more focused name.
The name "Phoenix" does neither help to find the library nor does it help to decide whether to have a certain feature included or not. Want MPL inside Phoenix? Er, well, yes, why not? Want Graph functionality? Yeah, would be great to be able to draw up relationships between Phoenix actors. Sorry, I might be exaggerating...
Points well taken. However, I would like to preserve that right. In as much as I am not forcing anyone to choose names, I don't relish the thought that I'll be forced to choose some name like "Boost::FunctionalProgramming".
Phoenix: ======== Now Phoenix is about to be taken out of Spirit which is good for both Spirit and Phoenix, I guess. From what I have read so far, Phoenix seems to have very powerful features. It deserves to live outside Spirit.
But many of Phoenix' features seem to be variants (improved, probably) of exisiting things like bind, lambda, ref, functional. I consider this a problem, because when I am going to need lambda functionality for example, should I turn to phoenix? Or to the lambda package?
Personally I would prefer either of the following two:
a) Phonix is split up into several smaller packages with most of them being merged/combined with exisiting ones.
b) Phonix is renamed into something like Boost::FunctionalProgramming and is merged with the exisiting packages.
With both options, when I am going to need lambda or bind in the future, I will know where to look for them.
The text on the first page of the documentation supports these thoughts IMHO:
"One can extract and use only a small subset of the full library, literally tearing the library into small pieces, without fear that the pieces won't work anymore."
May I request you to review the discussions and history/context from the Boost list? These issues are part of the discussions. I would urge you to reply on these matters in the relevant threads.
My vote: ======== 1) Before accepting Phoenix as boost library, its relationships with (competing?) packages of similar nature should be resolved. Having everything more than once is not helpful. Personally I am in favor of smaller, more focused packages, so I would choose option a)
Understood. I hope the discussions/threads related to this matters will shed light on what the current consensus is.
2) Before accepting it as boost library, a different name should be chosen. One that tells what the library is about.
Point well taken. Is it a condition for your vote?
PS: As for the background information:
- Are you knowledgeable about the problem domain? I am not an FP expert, but I've tasted blood and want more...
:-)
- What is your evaluation of the design? Not being an expert, I say, I am quite fascinated :-)
- What is your evaluation of the implementation? Haven't looked into the code, yet
- What is your evaluation of the documentation? I am going to send se separate mail.
- What is your evaluation of the potential usefulness of the library? As I wrote above, I think it would gain from being merged with existing libraries either to form a greater whole or to form several specialized packages.
Agreed. That's exactly the current consensus. FYI, that was the plan and one of the prime reasons for the review. You'll know for sure once you learn more about the history and context as they are being discussed in the other list.
- Did you try to use the library? With what compiler? Did you have any problems? Yes, I played with the "real life" example, tried to turn it into a a real "real life" example and failed utterly. Code is attached. Certainly shows that I am not an expert ;-)
Here's the correct code: // Find the first odd number in container c iterator it = find_if(c.begin(), c.end(), bind(&simple::value_, arg1) % 2 == 1); if (it != c.end()) cout << it->value_ << endl; // if found, print the result
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Several hours of reading and playing around, collecting thoughts in this mail and the next one in parallel. Not nearly as much as I wanted, but I got stuck with the documentation
Thank you for your review. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net