Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66938
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.173 as permitted sender)
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>
 <CABBJUpdvFw4aTkauzpv1gBuZxLBLgpwbJe-mLbSgdKgn4YzhXA@mail.gmail.com> <CAPwsocEUUpJp2rm8cS71uiSMC2zM2TWoaDUryK6u4bdwzwgOAg@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAPwsocEUUpJp2rm8cS71uiSMC2zM2TWoaDUryK6u4bdwzwgOAg@mail.gmail.com>
Date: Thu, 4 Apr 2013 17:59:36 +0800
Message-ID: <7848763017118166753@unknownmsgid>
To: Leigh <leight@gmail.com>
Cc: Laruence <laruence@php.net>, Hannes Magnusson <hannes.magnusson@gmail.com>, 
	Stas Malyshev <smalyshev@sugarcrm.com>, Ferenc Kovacs <tyra3l@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01175e7dc74fad04d9860735
Subject: Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers
From: laruence@gmail.com (Xinchen Hui)

--089e01175e7dc74fad04d9860735
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84 iPhone

=E5=9C=A8 2013-4-4=EF=BC=8C16:36=EF=BC=8CLeigh <leight@gmail.com> =E5=86=99=
=E9=81=93=EF=BC=9A

I find this somewhat conflicting.

If it's experimental, and will likely be removed because nobody will
maintain it, why is anything being added to it at all?

Maintaining it.


This simply makes it easier for people to build a dependance on a feature
that will ultimately cease to exist in the next major version.

Next after next.


It's black and white in my opinion. Support it or don't support it.

Experiment doesn't means never imperove it , right?

Thanks

On 4 April 2013 06:34, Laruence <laruence@php.net> wrote:

> 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 o=
ut
> > > (or not if turns out it is out of consensus). The point here is not t=
o
> > > 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/
>

--089e01175e7dc74fad04d9860735--