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