Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66933
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <CADNQb0VozXEaA_HV38bZs0yrMUSrUf15XZno4So9YAn4RLyW5g@mail.gmail.com>
References: <CABBJUpexRYZaXi10UobucCzJUXsLLK9avs+WspdSxyE4vDJ2rA@mail.gmail.com>
 <CADNQb0Uo0u2xCbR_joWKmwN9z+77nN-cLQ=Lcq2gpr0hf_A2qA@mail.gmail.com>
 <CABBJUpfx__wLqtG0w1SQzveggPiWubGLkPUJMFL+27cz3P_GyQ@mail.gmail.com>
 <CABBJUpcHuBT6schJm9gDe_tyz=Gvj53dNcs9UKbj2w040pCsiw@mail.gmail.com>
 <515BE6C2.7000801@sugarcrm.com> <CABBJUpfFeCwR_L59OsD7ZTtnL4=cNr6HW_boYneUFjKxjKVsqQ@mail.gmail.com>
 <CAH-PCH5Lr+yeiXwL0PjRb_M3ki6pPCLdMLCRMjqWE2GvM5H7kw@mail.gmail.com>
 <CADNQb0XeOE62m-ii-13g637C=RRdtH2j9jSnXB7OkLYwhE7bvw@mail.gmail.com>
 <515C9878.8060603@sugarcrm.com> <CADNQb0VozXEaA_HV38bZs0yrMUSrUf15XZno4So9YAn4RLyW5g@mail.gmail.com>
Date: Thu, 4 Apr 2013 13:34:10 +0800
Message-ID: <CABBJUpdvFw4aTkauzpv1gBuZxLBLgpwbJe-mLbSgdKgn4YzhXA@mail.gmail.com>
To: Hannes Magnusson <hannes.magnusson@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Ferenc Kovacs <tyra3l@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f83abd721b8b104d98253e2
Subject: Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
From: laruence@php.net (Laruence)

--e89a8f83abd721b8b104d98253e2
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 4, 2013 at 5:37 AM, Hannes Magnusson <hannes.magnusson@gmail.com
> wrote:

> On Wed, Apr 3, 2013 at 2:00 PM, Stas Malyshev <smalyshev@sugarcrm.com>
> wrote:
> > Hi!
> >
> >> There is absolutely no need for a RFC for it.
> >> Heck, even that initial curtesy mail was more then I would have
> expected.
> >
> > Agree, no need for full scale RFC for one constant. However, sending an
> > email to the list and actually waiting for feedback is exactly what I
> > would expect, especially dealing with stable version and feature that it
> > is not exactly clear what's going on with it. We're not talking about
> > writing RFCs for every minor change, we're talking about teamwork and
> > have members of the team be aware of the change and have time to discuss
> > it if needed. Nothing bad would happen if the same commit would land a
> > week later, after everybody is behind it and every detail is hashed out
> > (or not if turns out it is out of consensus). The point here is not to
> > impede work but to support teamwork.
>
>
> There is a thin line between impeding work and team work for such a
> trivial change.
> This constant is actually really useful.
> The entire feature is however unfortunately broken, but had it been in
> a working shape then common. Really? Send an email and wait a week
> before being able to write a testcase?
>
> Anyway. Lets move on.
> I suspect removing an experimental feature in an extension that is
> disabled by default and requires external library still requires an
> RFC?
> And according to the current rules of the game it cannot be removed in
> 5.5.1, but has to be removed in 5.6.0?
>
Hey:

I am afraid yes, we can only remove it in 5.6.

now, since I already commit it (I am sorry for rushing then).

and you all agree that the constant is useful,  so I think it's okey to
change the constant's name from curl_wrappers_enable

to curl_wrappers_enabled, and only defined when curl is built with
--with-curlwrappers.

then user can simply use  if (defined(CURL_WRAPPERS_ENABLED) {}

after this,  we can move on to write a RFC about remove the experiment
feature in 5.6, okey?

thanks

>
> -Hannes
>



-- 
Laruence  Xinchen Hui
http://www.laruence.com/

--e89a8f83abd721b8b104d98253e2--