Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66937 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 62627 invoked from network); 4 Apr 2013 08:36:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Apr 2013 08:36:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=leight@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=leight@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender) X-PHP-List-Original-Sender: leight@gmail.com X-Host-Fingerprint: 209.85.212.171 mail-wi0-f171.google.com Received: from [209.85.212.171] ([209.85.212.171:42478] helo=mail-wi0-f171.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 08/92-46468-E8B3D515 for ; Thu, 04 Apr 2013 03:36:31 -0500 Received: by mail-wi0-f171.google.com with SMTP id hn17so4436918wib.16 for ; Thu, 04 Apr 2013 01:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qHp7o+e9WOJz+RfKR2kNbBWdEFhHEsayWuPEqIcY2eI=; b=Vk28HZLxO+jRi3sB9Qv0xSDba0/RstcqwKSJy5nmbfila7jkHD3XoO+zKCBjiaX54q GU8yKauRwDkVw8bNDjlT7vjw8BJvKg9N79+65meLRJ9K07r75BO7chFUf2nyX91NuTCN 4EJWTL8AAMx8Zp1QMnZB0iaZ+UDUkJK7h/Xtv2i4PdjYY0zqdPRgZ7w0RTPBxW89Ypml B1mT85XPJWFFVz53Am2bxW7yBZXDKCY0tZVKioOFDLbBrTEre0sY51DGFPMCPxNx78mc MHAFRRUNB6XMcYy5lyz+2mh4G6RMHZaQIa5VmZ2robvBpu7qadFXm6OshZFGzIwYneII 1gog== MIME-Version: 1.0 X-Received: by 10.194.87.229 with SMTP id bb5mr7900621wjb.32.1365064587374; Thu, 04 Apr 2013 01:36:27 -0700 (PDT) Received: by 10.217.2.209 with HTTP; Thu, 4 Apr 2013 01:36:27 -0700 (PDT) In-Reply-To: References: <515BE6C2.7000801@sugarcrm.com> <515C9878.8060603@sugarcrm.com> Date: Thu, 4 Apr 2013 09:36:27 +0100 Message-ID: To: Laruence Cc: Hannes Magnusson , Stas Malyshev , Ferenc Kovacs , PHP Internals Content-Type: multipart/alternative; boundary=089e0102ffead3780b04d984dd16 Subject: Re: [PHP-DEV] Add a constant to reflect --with-curlwrappers From: leight@gmail.com (Leigh) --089e0102ffead3780b04d984dd16 Content-Type: text/plain; charset=ISO-8859-1 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? 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. It's black and white in my opinion. Support it or don't support it. On 4 April 2013 06:34, Laruence 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 > > 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/ > --089e0102ffead3780b04d984dd16--