Boost logo

Boost :

Subject: Re: [boost] [phoenix] Upcoming release - What about the rest?
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-03-18 07:02:28


On Fri, Mar 18, 2011 at 1:16 AM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 3/17/2011 5:51 PM, Thomas Heller wrote:
>>
>> Hi all,
>>
>> The next boost release is nearing and I want to include Phoenix.
>> However, there are some questions that needs to be solved.
>>
>> How to deal with Boost.Bind and Boost.Lambda?
>> First of all, I don't think its a good idea to remove either of those.
>> However, should Phoenix deprecate Boost.Bind and Boost.Lambda?
>
> Phoenix should not deprecate anything. Boost will probably decide to
> deprecate Boost.Bind and Boost.Lambda eventually. Getting Phoenix into Boost
> for 1.4.7 is right now most important.

Ok, bad wording on my side ...

>> If yes, how should this deprecation be handled?
>> My main concern is that most users will just continue to use BB and
>> BLL just because of their names.
>
> So they do. It's not breaking Phoenix if that happens, is it ?

Of course not, but ...

> If Phoenix is better it will be used. There is no need to pull the rug from Bind
> or Lambda to force end-users to change, or even worry about it now.

I don't want to force users to change, I just want to present them a
more or less official Guideline like:
Ok folks, we have Phoenix now, if your compiler supports it, use it from now on.

> If and when that change happens Boost can always look to switch end-users from
> Bind and/or Lambda in the future by not supporting those libraries anymore and/or
> pulling them from the Boost distribution.

Again, I don't want it to be removed from Boost. Boost.Bind still has
some advantages over Phoenix ...

And I am talking about new users. Many libraries use function objects
and advocate the use of Boost.Bind. I don't think it will change much
... however, IMHO, there needs to be better transparency that
phoenix::bind is a valid and more versatile drop-in replacement for
Boost.Bind.

>> What about Phoenix V2?
>> For V2 I have a clearer vision. I would like to have three phases:
>> 1) Have V2 and V3 coexist in the tree, have a macro that decides which
>> version
>>     should be included. will default to V2
>> 2) deprecate V2, change the default of the macro introduced in 1) to V3
>> Alternatives:
>> 3 a) remove phoenix v2
>> 3 b) move phoenix v2 to another namespace so that V3 and V2 don't
>> interfere anymore
>
> Either 1 or 2, but just document it.

Oh no, i didn't mean to say 1) or 2) its more like a schedule:

First do 1) then advance to 2) after N (N>=1) releases if everything
went fine. We can decide about 3) later ...

> C'mon Thomas and Phoenix developers, get Phoenix into 1.4.7 with proper
> documents about it and how to use it, and worry about Bind, Lambda, and
> Phoenix 2 some time later. There will be plenty of time for that once
> Phoenix officially gets into Boost and developers, like me, start using it
> who would not have done so before because it was never officially a Boost
> library and finding its documentation and how to use it was nearly
> impossible.

Its not a technical issue ... its a "political".
I just wanted to avoid user confusion before the release ... and avoid
the need to act as quickly as possible after the release when users
show the confusion ...
I don't think this will stop Phoenix from being included in the 1.47 release ...
Such a decision can be made rather quickly.
I am fine if the decision will be "just release it, we will see
later", but not really happy about it.

Best regards,

Thomas


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