Re: [boost] [Review] Phoenix review starts today, September 21st

Subject: Re: [boost] [Review] Phoenix review starts today, September 21st
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-29 09:33:02

On Mon, Sep 29, 2008 at 3:19 PM, Joel de Guzman
<joel_at_[hidden]> wrote:
> David Abrahams wrote:
>>
>> on Sun Sep 28 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
>>
>>>> I think one difference here may be that Joel already knows he has
>>>> interface-breaking changes planned (if that's not actually the case, I
>>>> apologize).  Several libraries have had interface-breaking changes after
>>>> acceptance, but AFAIK these were not anticipated at the time of the
>>>> review.
>>>
>>> Yes, I do anticipate interface-breaking changes. The proto port (What
>>> we call V3) is special because it actually captures a lot of what I
>>> had in mind for the next revision. I also expect, as typical with
>>> a review, more changes that I haven't foreseen. The suggested "optional-
>>> laziness" and the new and improved switch_ syntax, are two such cases
>>> of high consideration. I thought it would make sense to addess all
>>> these in one step.
>>>
>>> Again, let me reiterate, that despite all these changes, the design
>>> and implementation or V2 is still sound, and IMO, pretty much up
>>> to standards with Boost quality. It is still the solid basis for
>>> V3 with up to 95% of the interface intact and essentially unchanged
>>> design and structure.
>>
>> In case *I* wasn't sufficiently clear about it, let me try to be
>> painfully explicit: we may want to discuss whether it's good for Boost
>> or its users if we release a new top-level library and then break its
>> interface in the next release, three months later.  I'm all for
>> accepting some version of Phoenix, but I want to make sure that users'
>> needs for -- and the public perception of -- Boost's stability are
>> accounted for.
>
> Agreed 100%. I wouldn't want to have a release that will be good for
> only a few months and break the interface in the next release.
> That's the last thing I would want to do. I value stability.
>

So, assuming that phoenix will be accepted, on what will be based as
the first official phoenix release in boost? On the current
implementation (with minor improvements like result_of compatiblity)
or on a  proto-based variant (like phoenix v3).

In the first case it means that when-if a proto based is available, it
might break compatibility with any eventual user extensions.

In the second case it is a bit tricky for a reviewer point of view,
because part of the library under review (notably the extension hooks)
is not what will end up in boost.

Even if the second point were the adopted solution, I would still vote
in favor of Phoenix because, seeing the precedents, I would trust Joel
to come up with a good implementation, but I think it would be a bit
against the spirit of a boost review.

Note that I think that the extension interface (and its documentation)
is the most important part of Phoenix because, IMHO, it is where the
"added value" with respect to boost.lambda lies.

The best solution would be that the implementation that goes into
boost will be based on proto *and* will retain more or less the same
extension interface.

-- 
gpd