Re: [Boost-users] [Phoenix] review reminder

Subject: Re: [Boost-users] [Phoenix] review reminder
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-09-30 00:17:37

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