Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84593 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39974 invoked from network); 11 Mar 2015 22:42:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Mar 2015 22:42:39 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.101 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.101 blu004-omc2s26.hotmail.com Received: from [65.55.111.101] ([65.55.111.101:52730] helo=BLU004-OMC2S26.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 42/38-32765-DD4C0055 for ; Wed, 11 Mar 2015 17:42:38 -0500 Received: from BLU436-SMTP210 ([65.55.111.72]) by BLU004-OMC2S26.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 11 Mar 2015 15:42:36 -0700 X-TMN: [z9PlEviQBX/Ptc98NkLgWOW6TbrUkONk] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: Date: Wed, 11 Mar 2015 23:42:31 +0100 CC: PHP internals Content-Transfer-Encoding: quoted-printable References: To: =?utf-8?Q?Pavel_Kou=C5=99il?= X-Mailer: Apple Mail (2.2070.6) X-OriginalArrivalTime: 11 Mar 2015 22:42:33.0671 (UTC) FILETIME=[AA367570:01D05C4C] Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types From: bobwei9@hotmail.com (Bob Weinand) > Am 11.03.2015 um 23:29 schrieb Pavel Kou=C5=99il : >=20 >>> It shouldn't prevent any future improvements and still give use all = the >> advantages of scalar types. >>=20 >> Besides what I think of proposing yet another RFC, -1 because it is >> basically what the initial idea from the opponents of optional strict = mode >> wanted before they go with the latest one. It also totally ignore = what the >> Anthony's proposes. >>=20 >=20 > Hello, >=20 > I'd say that this is definitely better than the dual mode RFC, but > worse than the coercive one - I can't find a single reason why some > modes switch should be good. I can only see negative outcomes from > this, and a painful experience when developing with PHP in the long > run as a userland developer. >=20 > Basically goes with what I've been saying from the beggining of the > introduction of the "dual mode" - I don't care if strong or weak > typing wins, but I want only on in the language. PHP is inconsistent, > there's no need to make even more inconsistencies and stuff. >=20 > Regards > Pavel Kouril It's not worse than the coercive one. It's just doing less. It doesn't = change ZPP. We always still can change ZPP later in future. If you like the coercive one, you also should like this one. Bob=