Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85025 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71554 invoked from network); 16 Mar 2015 11:30:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2015 11:30:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:51931] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FA/50-03331-DEEB6055 for ; Mon, 16 Mar 2015 06:30:54 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 6F979E202F; Mon, 16 Mar 2015 11:30:49 +0000 (GMT) Date: Mon, 16 Mar 2015 11:30:49 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: Yasuo Ohgaki cc: Pierre Joye , PHP internals , Dennis Birkholz In-Reply-To: Message-ID: References: <55066F07.80308@birkholz.biz> <5506794B.8090008@birkholz.biz> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-66928591-1426505450=:4205" Subject: Re: [PHP-DEV] About declare(strict_types = 1) From: derick@php.net (Derick Rethans) --8323329-66928591-1426505450=:4205 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 16 Mar 2015, Yasuo Ohgaki wrote: > On Mon, Mar 16, 2015 at 5:17 PM, Pierre Joye wrote= : >=20 > > On Mar 16, 2015 6:46 PM, "Yasuo Ohgaki" wrote: > > > > > > On Mon, Mar 16, 2015 at 3:33 PM, Dennis Birkholz > > > wrote: > > > > > > > Am 16.03.2015 um 07:22 schrieb Yasuo Ohgaki: > > > > > > > > > Caller _must_ satisfy callee requirements. This is simple=20 > > > > > principle to write a secure code. > > > > > > > > > > With this RFC, caller overrides security related setting. This=20 > > > > > means scripts that are prepared for type safety is "ignored"=20 > > > > > and it leads security breach. That's not true. The caller does not override any security setting. The=20 receiving function (callee) will *always* get the type they declared.=20 *That* is important for security. When I first saw Andrea's v3, I was also of the opinion that it should=20 be the callee that controls whether the type hints should be strict or=20 not. But then I realized that it *does not matter*, as the callee will=20 get the right type regardless. Allowing the caller to decide whether it=20 throws an error or not, is irrelevant to any sort of security. Realizing=20 that it didn't matter, made me change my "no" vote to "yes". > I thought majority of us see the benefit of StrictSTH over this RFC.=20 > You're right about it. >=20 > This RFC will have serious consequence. We made mistake with=20 > "safe_mode". The main reason it failed is "it did not force caller to=20 > have responsibility to make it work as it should". This RFC does the=20 > same for how declare(strict_types=3D1) works. >=20 > Aren't we learned from "safe_mode" lessons? I am not sure why you mention "safe_mode" as this has absolutely nothing=20 to do with scalar type hints. Not feature wise, not implementation wise. safe_mode, first of all, was a global INI setting. The developer=20 couldn't turn it off easily. That was probably at least 80% of the pain.=20 The second part was the name, as it indicated that it made your scripts=20 safe: It didn't. STHv5 does not suffer from either issue =E2=80=94 developers can pick and c= hoose=20 the best solution for *them* (give them some credit, most developers are=20 actually smart!). Library authors always get the right type if they type=20 hint, which is *their* main pain point. And the type names have always=20 already been used for casts anyway, and don't include "safe" in their=20 name. cheers, Derick --8323329-66928591-1426505450=:4205--