Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102864 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23116 invoked from network); 16 Jul 2018 17:23:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jul 2018 17:23:56 -0000 Authentication-Results: pb1.pair.com header.from=mitke013@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=mitke013@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.49 as permitted sender) X-PHP-List-Original-Sender: mitke013@gmail.com X-Host-Fingerprint: 209.85.218.49 mail-oi0-f49.google.com Received: from [209.85.218.49] ([209.85.218.49:37603] helo=mail-oi0-f49.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D6/B0-39793-CA4DC4B5 for ; Mon, 16 Jul 2018 13:23:56 -0400 Received: by mail-oi0-f49.google.com with SMTP id k81-v6so76224326oib.4 for ; Mon, 16 Jul 2018 10:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WDehH65HsJnOTbPsL2qK0m9b4gdjLqiurbc8NF99/W0=; b=eWZyrTbJybIIqMGnUTLqahCdLlLXH0Z4ObNye5wcxLd25eZgnkhXRGYAd0xgofJqZ6 ebgL3BoBuDiDIeHj06zK0/fnLIF+CkrA8HtcJZXNkN9Qjq4qU7FsKtVs/NodfMAHAmoE RTh5pxMbydd57BD7TLKfE2V6LkLon26plsKPe/dEE/y00kJSiBOwEc9lvXPtZxf3P3pc e0S1VhQRQC0g43VekIyf9Mj8ooWjkJReqaTbQLpG/8DRxJxTt7QYDmZ1sTkvPuZqFbIX 1uBi/pY4lTFCEkZ1gUYiz5SvnTaiJoyDsVao06UAvCXlPE+Xyu7DglO937GlRWqopBF8 /DQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WDehH65HsJnOTbPsL2qK0m9b4gdjLqiurbc8NF99/W0=; b=oTj04f7J5Dl/r1tlnmQHqvbGwsJf9J3SkykItI08NUNsfmkcyrVmQ6dW6cxt3JZejA 9aWhUhK2CmUc9fTDse3INZ/aCsfg0t5/rmsoNUGNk+DNFu5vqyBZCWEwxItKZK8Oa0i0 AWabUNmlyqdQ5CMEuw2mkuy0SUJfvTxLtiV69DNNnvO0MxavyLKzwsXkpONTKP3W9Q/j eKc2gQiwTQsh49nA2rLwPRwTG9Pi988IRH6liR4EqKzFbUAztLchF3QiBsp0Yfrzhlza 7WpPNEnOP2AKnRT5X4dP1k2S2f2C07Db2VFIwwPJcCv4c3ARc9km9t4CCgkgKuMx788K DF2A== X-Gm-Message-State: AOUpUlGHlpI8fmOMaPeOlt569+Y2bNAhkYFd7oAOLDlOcSN8v9i1w+21 uPKYwuaC0XblKsbX/S6VVJknSICH9vgc3D+8I8U= X-Google-Smtp-Source: AAOMgpehwSBqkUmz/LEaxjdPTux87CHSZcrAtfqtLCKLntf/mHEZxzzgGCx1PKLT3Smh0VInqn++k1RTA1BcsB09c6M= X-Received: by 2002:aca:69d0:: with SMTP id e199-v6mr245611oic.286.1531761833861; Mon, 16 Jul 2018 10:23:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 16 Jul 2018 19:23:42 +0200 Message-ID: To: rowan.collins@gmail.com Cc: Arvids Godjuks , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000fce767057121179f" Subject: Re: [PHP-DEV] [RFC] Optional typehint check for parameters From: mitke013@gmail.com (Zeljko Mitic) --000000000000fce767057121179f Content-Type: text/plain; charset="UTF-8" On Mon, Jul 16, 2018 at 1:42 PM Rowan Collins wrote: > On 16 July 2018 at 12:06, Arvids Godjuks wrote: > >> Basically, you went wrong when you proposed a switch that controlls >> language behavior. To add to that - a switch that probably is not >> controllable by code that is running. >> > > > While I agree with your general principle here, I would like to raise one > point in this proposal's favour, which is that PHP's type hints are > effectively assertions - if the value is not of the given type at that > point, an error is raised. Assertions are always something you turn off in > production builds, with a global switch, to the point of compiling the code > as though they don't exist, so it's not unreasonable to have a similar > switch to disable run-time type checks. > > As Nikita points out, this is not true of non-strict scalar hints, so that > does raise a complication. > > I was going to point to Dart as an example where type checks have been > implemented this way, but it seems that version 2 has replaced the "checked > mode" with stronger static analysis, and run-time checks are automatically > inserted only for cases where the safety can't be inferred. > > This might actually be a more promising optimisation for PHP - perhaps > OpCache could mark certain code paths as type-safe (or maybe it already > does?) As an exaggerated example, this code only really needs to check the > value's type once, not four times: > > function foo(Bar $bar): Bar { > return $bar; > } > function test(Bar $bar): Bar { > return foo($bar); > } > $something = test($something); > > Regards, > -- > Rowan Collins > [IMSoP] > Exactly. Languages like Java and Hack will not compile when sent parameter is of wrong type. Once all is OK, generated code will never check that value again. My suggestion is something between; if during development my code works, I don't ever need type check again. it doesn't have to be php.ini configuration. Maybe even better solution would be to have different PHP installation. Example, instead of "apt install php7.2", user would do "apt install php7.2-nocheck". So if opcode-equivalent of php7.2.exe looks like this: --- assert_type(User, TypeError) some opcode 1 some opcode 2 --- in that other php7.2-nocheck.exe, opcode would look: --- some opcode 1 some opcode 2 --- Or if it is simpler, assert_type would be blank opcode. It is similar to how Symfony works; using compiler passes, programmer can replace slow service with faster one, as long as it is same interface. For example logger service; in production, I don't need most of stuff written to log file as I need in development mode. So instead of constantly checking which environment my code is running in, I always use $logger->info('something'). But in production, expensive logger service is replaced with one that has no code in that method. Hopefully I explained it correctly, although this logger example is fictional. --000000000000fce767057121179f--