Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78238 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81462 invoked from network); 22 Oct 2014 19:29:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Oct 2014 19:29:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.115 smtp115.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.115] ([108.166.43.115:50780] helo=smtp115.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 27/E2-63701-38508445 for ; Wed, 22 Oct 2014 15:29:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 354C7380256; Wed, 22 Oct 2014 15:29:05 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id A7EE138013A; Wed, 22 Oct 2014 15:29:04 -0400 (EDT) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local (108-66-6-48.lightspeed.sntcca.sbcglobal.net [108.66.6.48]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.2.13); Wed, 22 Oct 2014 19:29:05 GMT Message-ID: <54480580.9040302@sugarcrm.com> Date: Wed, 22 Oct 2014 12:29:04 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Andrea Faulds , Zeev Suraski CC: Dmitry Stogov , PHP Internals References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <866A39C7-6F11-408D-8BCA-594BA22E8569@ajf.me> <5447682B.2080100@sugarcrm.com> <019325A5-4F82-4179-B4D7-29E5649B2616@ajf.me> In-Reply-To: <019325A5-4F82-4179-B4D7-29E5649B2616@ajf.me> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > No, it wouldn’t require a 2/3 majority. The optimisation me and > Dmitry are referring to is merely an optimisation, it’s an > implementation detail. This doesn’t touch any of the language spec or > the language as understood by users. Sorry, it's not "merely an optimization", it's making it an engine primitive, like (int) or empty() are. > Or would you argue that the fact is_long is now an opcode is a > language change, and Dmitry should’ve made an RFC before making a > change that is completely non-user-facing?! is_long existed long before that, and nothing changed for it. You propose to add completely new type conversion rules into the engine, in addition to ones already present and used there. It's not the same as merely changing how the engine internally runs pre-existing code. The new rules are definitely becoming major part of the language, not an implementation detail of some random function like str_pad. Saying "oh, we just add it like a random function and _only then_ we'll make it an opcode and it will be implementation detail" sounds a lot like gaming the system to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/