Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80603 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2574 invoked from network); 16 Jan 2015 00:25:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jan 2015 00:25:38 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender) X-PHP-List-Original-Sender: smalyshev@gmail.com X-Host-Fingerprint: 209.85.214.172 mail-ob0-f172.google.com Received: from [209.85.214.172] ([209.85.214.172:62275] helo=mail-ob0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0D/70-33406-08A58B45 for ; Thu, 15 Jan 2015 19:25:37 -0500 Received: by mail-ob0-f172.google.com with SMTP id va8so16543296obc.3 for ; Thu, 15 Jan 2015 16:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kPegu91FWiTBKbUlk2oq4vulkfzpz6hhMMvXxVoin/E=; b=XRyA9GNze0x0y1QgS6x/+aGx4c+MCdju3lsnBYoboLXWgoz2lvstFXEO+zHwmU/PvV NRHH05uR5/dtthwgkNxcW0J5piWyADgoOqrpSUkuixGErE3VGPx9Z7gnpcGcrtQ2Hsyq 9Fp8ou5fIZ3aERndyGeHIV7FUR1jxAZ/7BSI3exSknQ0Uuzyp5nw7c0ZUJkMnaVTINra jLv3XVDv8s+XQ0EHQEqTDJ9ucZTE08PpSltjMvYihbEBuDyZ8InT8b5cZNaesjr5ob+7 Ak/SHzgUwxA+Pqcmvbjm4kmJ9TXT0DXzJIqF0P94ha7UR0ZNNkT9eqwrk1QZVhIJYs61 xQrA== X-Received: by 10.182.231.230 with SMTP id tj6mr7865986obc.58.1421367934003; Thu, 15 Jan 2015 16:25:34 -0800 (PST) Received: from Stas-Air.local (108-66-6-48.lightspeed.sntcca.sbcglobal.net. [108.66.6.48]) by mx.google.com with ESMTPSA id mq8sm778885oeb.2.2015.01.15.16.25.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Jan 2015 16:25:33 -0800 (PST) Message-ID: <54B85A78.5000109@gmail.com> Date: Thu, 15 Jan 2015 16:25:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrea Faulds , Zeev Suraski CC: RQuadling@gmail.com, Leigh , PHP Internals List References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me> In-Reply-To: <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2 From: smalyshev@gmail.com (Stanislav Malyshev) Hi! > I’m not really sure this is true. I agree that strict types aren’t > entirely in keeping with the “PHP way”. However, there are plenty of > people who are against them not for that reason, but simply because > they don’t work well for them. Plus, I’m not sure strict typing I would say for myself it is both. Having PHP code that thinks 1 can not be used as boolean true just feels wrong philosophically, but on top of that I imaging how much (type) conversions I'd have to use to deal with strictly-typed code in practice - it makes me sad for practical reasons. > weakly-typed. Indeed, strict type hints don’t stop PHP being > weakly-typed. They just check types at function call boundaries. "Strict types don't stop PHP being weakly typed". No, that doesn't work. Adding misleading word "hints" doesn't help either. What happens is that with this proposal PHP would be partly strictly typed and partly weakly typed. Which would be subject of both confusion and criticism about language not being consistent - in one context it's fine to use 1 as boolean, in another it's not, the fun is in the remembering where is which. > This is unlikely to be super-representative of the PHP community. It's not even representative of the list, that's why we have votes :) Claiming vote result pre-vote seems to be not very useful. > Except that is not the case for this proposal, which explicitly and > deliberately prevents the directive affecting inclusion. The > behaviour is impossible to toggle at runtime, unless you’re using > some weird extension which lets you edit the flag on the > ZEND_DO_FCALL opcode. ZEND_DO_FCALL is not by far the only way to call a function. There are many other ways. Keeping them all in sync and tracking the proper context for each of them would be a very fun exercise. That's why state-dependent behaviors usually aren't a good idea, especially if state happens in one place and behavior in another. -- Stas Malyshev smalyshev@gmail.com