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

Subject: Re: [Boost-users] [Phoenix] review reminder
From: Roland Bock (rbock_at_[hidden])
Date: 2008-09-30 03:11:45

Hi Joel,

sorry, I am not on the boost.devel list and I did not read the 
discussion there. I admit that I am new to public review and obviously 
did look not in all available places. I promise to catch up :-)

My vote does not depend on the name of the library. I consider the 
things I learned about Phoenix so far pretty amazing! And I am in favor 
of the library being accepted in boost.

I just wanted to state that from my limited experience (about 15 years 
of development and about 10 years of coordinating a small team), I say 
that selfexplanatory names for variables, methods, classes and libraries 
are very helpful in the long run. I certainly don't want to force 
anybody. I had hoped to be able to convince you. But again, my vote does 
not depend on it :-)

Thanks for your answers!

Regards,

Roland

Joel de Guzman wrote:
> 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,