Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83567 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52129 invoked from network); 23 Feb 2015 12:59:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Feb 2015 12:59:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:10352] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 83/2F-01128-8142BE45 for ; Mon, 23 Feb 2015 07:59:04 -0500 Received: from moorea (unknown [82.240.16.115]) by smtp2-g21.free.fr (Postfix) with ESMTP id 90B534B01DD; Mon, 23 Feb 2015 13:58:49 +0100 (CET) Reply-To: To: "'Joe Watkins'" , "'Zeev Suraski'" Cc: "'PHP internals'" References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com> <54EA5EDA.8010605@gmail.com> <54EA6A99.5010609@gmail.com> <54EA7F15.9030606@gmail.com> <54EA891B.6030405@gmail.com> <09b9ee836c04b1750614a91bd39a5bed@mail.gmail.com> <54EA97A2.4010701@gmail.com> <661590f4daa710176268b43c1b950583@mail.gmail.com> In-Reply-To: Date: Mon, 23 Feb 2015 13:58:57 +0100 Message-ID: <073001d04f68$7d155ed0$77401c70$@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDXD7ehmaYKzbAddTs7O1sB4MzmgIw+OLdAe4e2iYCibfnDQEmdWqtAiDZcfAB4cR2SQJXxpD6Ais01rQBOuFyBwIXH55kA0f2RCABOSCiv5vWu3bw Content-Language: fr X-Antivirus: avast! (VPS 150223-0, 23/02/2015), Outbound message X-Antivirus-Status: Clean Subject: RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC) From: francois@php.net (=?utf-8?Q?Fran=C3=A7ois_Laupretre?=) Hi, > De : Joe Watkins [mailto:pthreads@pthreads.org] > > > If you can infer the type with confidence, you can do away with = coercion > code altogether. >=20 > Maybe I'm ignorant of something, but isn't the only way you can begin = to > infer the type with real confidence is by having strict typed = parameters ? >=20 > This sounds like the kind of strict mode we're talking about, where no > coercion is necessary because inference is so reliable given a good > starting place (function entry with strictly typed parameters). 'Weak' mode also provides full confidence on parameter zval type at = function entry as they-re systematically converted. If you statically = analyze PHP code starting from this point, there's no difference. The = only difference is when you build the reverse tree of possible zval = types in the calling environment. But, in this case, strict types just = allow to restrict possible types as, in many cases, you cannot have = one-to-one matching. I hope we all agree now that, in most cases, compilers (at least static = ones) and code analyzers can provide smaller code and detect more = potential issues in so-called strict-typing mode. What we don't agree is = the downside of the architecture needed to allow this. Making a personal = decision is just putting the relative perception of both aspects in = balance. Let me be clear : if I didn't consider downsides more important than = benefits, I would be all for enabling future compilers and static = analyzers to be more performant. Anthony is an expert, the tools he = wants to build are potentially interesting for the whole community, he = knows his own needs better than anyone else. So, if I think this can be = satisfied without making it worse for the rest of the world, why would I = refuse, sadism ? Unfortunately, I think we have, at least, two major downsides here ; 1. the need for dual-mode. Actually, if we absolutely had to authorize = strict types, I would still prefer it being the only available mode. = Some will claim it's FUD but others will agree that no syntax or = mechanism to switch modes proposed so far was really satisfying. All = were more or less unintuitive and confusing, let alone the proposal to = shoehorn the concept by hacking the PHP syntax or possible ambiguities = against the E_STRICT concept. Even per-file activation may seem = attractive on a small codebase but would probably quickly become a = nightmare on a large one. I even know people currently writing composer = plugins to turn it on and off on a project basis, modifying every PHP = source files to add/remove the declare directive, which proves total = misunderstanding of the concept, but also that proposed mechanisms don't = fit so well with user needs. I wish good luck to the fooled users who = will naively use such massive editing tools to improve the quality of = their software... I have tried to explain from the beginning that, in = most cases, especially in software architecture, 1 + 1 is not 2, and = concatenating incompatible needs in an hybrid solution is not the same = as merging them in a 'compromise' unified one. I read that the dual-mode = RFC unifies people's needs. No, that's exactly the opposite. 2. the risk of seeing people massively consider strict mode as a way to = improve their code quality without understanding the implications, = potentially leading to a disaster. As I already wrote, debugging is too = often assimilated with a phase to suppress error messages, trusting the = compiler/interpreter, and considering that each error message implies an = underlying bug : "Look, the new PHP 7 strict mode is really fantastic. I = ran it on my legacy software and it detected 50 new bugs. PHP 5 was = really bad, to leave so many undetected !". Then, this would = automatically lead to massive explicit casting, as it is also natural to = think that constraining values enhances code quality, especially if it = is confirmed by the suppression of an error. The point is : we must = *never*, in any case, whatever the documentation we write to explain = this, allow the possibility of false errors. Don't get me wrong, people = are not more dumber and more incompetent than I am. We would be fully = responsible for giving them a trap, perfectly suited to fool them. In my = opinion, introducing such a false feeling of quality and security is a = terrible mistake. Regards Fran=C3=A7ois