Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78249 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5221 invoked from network); 22 Oct 2014 21:12:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Oct 2014 21:12:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.216 imap10-3.ox.privateemail.com Received: from [192.64.116.216] ([192.64.116.216:35677] helo=imap10-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/27-63701-7DD18445 for ; Wed, 22 Oct 2014 17:12:57 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id B9DD62400DD; Wed, 22 Oct 2014 17:12:52 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap10.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap10.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gjPtEDWMZMMP; Wed, 22 Oct 2014 17:12:52 -0400 (EDT) Received: from oa-res-26-28.wireless.abdn.ac.uk (oa-res-26-28.wireless.abdn.ac.uk [137.50.26.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 878232400DE; Wed, 22 Oct 2014 17:12:51 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) In-Reply-To: <54480F68.6010406@sugarcrm.com> Date: Wed, 22 Oct 2014 22:12:49 +0100 Cc: Zeev Suraski , Dmitry Stogov , PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: <058059C3-514C-4EA9-9468-3B9A8F20DCA8@ajf.me> 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> <54480580.9040302@sugarcrm.com> <4F848DB0-0266-46A0-9805-2B2BF22CAC33@ajf.me> <54480F68.6010406@sugarcrm.com> To: Stas Malyshev X-Mailer: Apple Mail (2.1990.1) Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions From: ajf@ajf.me (Andrea Faulds) > On 22 Oct 2014, at 21:11, Stas Malyshev = wrote: >=20 >>> 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. >>=20 >> No, they=E2=80=99re just a set of new validation functions. >=20 > No, they are not. They are new engine primitives for handling type > conversions. They=E2=80=99re not engine primitives. They=E2=80=99re a set of = validation functions. Now, later as an optimisation, these might end up becoming opcodes if = they=E2=80=99re used enough. Or, heck, this patch could do it. It = doesn=E2=80=99t make a blind bit of difference how something=E2=80=99s = implemented internally. If I get rid of all opcodes and replace them = with function calls internally, that=E2=80=99s not a language change. = The *language* has not changed. The way the Zend engine implements the = language, in a way that is not user-facing, has changed. Are you opposed to the existence of ext/filter given it has = FILTER_VALIDATE_INT, a =E2=80=9Cprimitive for handling type = conversions=E2=80=9D? -- Andrea Faulds http://ajf.me/