Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107706 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62214 invoked from network); 27 Oct 2019 04:25:37 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 27 Oct 2019 04:25:37 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 988E42D1FCE for ; Sat, 26 Oct 2019 19:12:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Sat, 26 Oct 2019 19:12:39 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id 4so2771012ybq.9 for ; Sat, 26 Oct 2019 19:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to; bh=+4lwPyd5+10flwA1VwnjkM2EjJGWEuhEEz+9oPVCc+0=; b=oZsC+NG+LsqwSukdVgfrAa80Qy4PP3QQ3bS+o0zdeRn8lo/7AV3D+/lGLf9XsamnMf YNaIcW37KPXS23qu074sei2kuYQ88SvmNMl44axZ+OGB7zRdwikft6cvkZUImbpbaKnG GhnmWKatAmNIfNEdHRf7TPzEObBi0SBwHduSSHr1zqsd/Aa67/yjbR9hrVJC8C7Iy3bM dB540vQJ4vcsDrE1wK6Y3Thvt/1x3FJMXJDHJXGHPOv4ZC1ZOyZRoS+9ZFsGuRiJH/eG NFff76Pn4mMcyUTRzCX5/7tRKGW7MgrLt2Vsz8ThKbtV3k3+o/70iBBGKbqb1p/ha944 Nq7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=+4lwPyd5+10flwA1VwnjkM2EjJGWEuhEEz+9oPVCc+0=; b=WMjbdlh7Dtx2DVJ14F1nXKFq9oBltsPpnTZDWoeZig0CyFq+eLbS1KCme3+xxcKBiA 5HJj5hOvdxoR2mX+5VLSAHv7O3TpmksLoZiWT1kr8O1yThA5ENxXpwDXuciepxD1ftht r2TVnjFYA55LTTb8TchjqDTOAlSUiy7LmOBmc3kUCiBWmaKJQqqDYqeeNbOpoR1gG07v WrcbW5Wj2qUf/XfdprPSMOyPKjZLCZfYEEZAd2zAW9aLk15GOcsHpmIVkYsVptgOYVzm 2Fn1uiAfcDK9g6VLjs6kdEzFg2NVzdfvwhl0JEmfqam3x+2kFcsWdBTry8W5upnkrtQV TQPw== X-Gm-Message-State: APjAAAXdcTdf0E06Qw1dB94ImuVqqI6Cq95n3qy3Ox+5ntLmWhEvaJO1 hxFxb/yqLZ0iRAAECuvILCOH7ScfOufnPA== X-Google-Smtp-Source: APXvYqxe/Sxyw3AtzEseviQZ3TSRoX7yQzzYjMG3Vs/KsMicSpEveW2r9Tip+aXCeWlm0OCp5OSkMA== X-Received: by 2002:a25:aae5:: with SMTP id t92mr9889518ybi.125.1572142358190; Sat, 26 Oct 2019 19:12:38 -0700 (PDT) Received: from ?IPv6:2601:c0:c680:5cc0:4846:f50e:1715:5361? ([2601:c0:c680:5cc0:4846:f50e:1715:5361]) by smtp.gmail.com with ESMTPSA id f194sm9685402ywb.53.2019.10.26.19.12.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Oct 2019 19:12:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AACE7C07-9F39-4642-AA7D-B0A9CD9588E9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: Date: Sat, 26 Oct 2019 22:12:35 -0400 Cc: Benjamin Morel , Dmitry Stogov To: PHP internals X-Mailer: Apple Mail (2.3445.104.11) X-Envelope-From: Subject: Optional pre-compiler for PHP8? From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_AACE7C07-9F39-4642-AA7D-B0A9CD9588E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all: While reading the [RFC] Union Types v2 thread and comments from = Dmitry[1], and especially Benjamin[2] who suggested "building a static = analysis tool which could prove that certain type checks would never = fail, and prime OpCache" it occurred to me that a PHP pre-compiler could = potentially be used to resolve numerous issues the community has been = debating. But first, let me define what I envision for a pre-compiler:=20 - A command-line tool that could take a PHP file and/or application and = generate pre-compiled files with an extension of .phpc or similar. - This of these .phpc files being implemented similar to .phar` files, = but actually compiled to a OpCache binary form. - Pre-compiled files would be deployed alongside .php files, or = optionally(?) standalone without PHP files. - Libraries and (WordPress) plugins could deliver pre-compiled files = too, alongside their .php source files - Command line switches could allow for: - Compiling with or without (selected) deprecations - Selected constants defined on the command line - Packaging code on a one-to-one per PHP file, as one file per = namespace, one file per app, etc. - The pre-compilation process would be able to: - Type-check everything that has type-hints - Do type checking that is too expensive to do at runtime - Pre-compiling:=20 - Could help eliminate the complexity of auto-loading and opening many = files, at least for pre-compiled code. - Would be an option for type checking and improved performance, but not = be required. If the PHP community were to embrace the idea of an optional = pre-compiler then we could see the following benefits: 1. Full type checking capability without any concerns for runtime = performance issues related to type checking. 2. Ability to significant improve performance over time, possibly even = more than a JIT model. 3. Potential to support optimized real types =E2=80=94 as in Hack =E2=80=94= where code needs to be highly performant=20 4. Ability to deprecate features for pre-compiled code while still = supporting them when not precompiled. While benefits #1 to #3 are highly valuable, consider benefit #4. If we = had such a pre-compiler than the concern for BC for pre-compiled code = could become moot as the deprecations would not affect any existing code = that is not pre-compiled. =20 This could potentially give us the best of both worlds? Further, those most interested in deprecations and moving to enterprisey = language features certainly use a CI/CD build process so it should be = not problem at all for them to incorporate a pre-compile step. Lastly, having such an optional process =E2=80=94 with its primary = promoted benefit being performance =E2=80=94 could be a great incentive = for those running less strict and backwards-compatible PHP code to = refactor their source code to gain greater performance. This contrasts = with deprecating features and breaking BC just "because it is a better = way to program." Give them a carrot rather than use a stick. So for those who know PHP's internal core code:=20 Is there any reason this is not technically viable? And for everyone:=20 What do you think of this as a potential future for PHP? -Mike [1] https://news-web.php.net/php.internals/107699 [2] https://news-web.php.net/php.internals/107702= --Apple-Mail=_AACE7C07-9F39-4642-AA7D-B0A9CD9588E9--