Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120094 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 61596 invoked from network); 21 Apr 2023 03:55:00 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Apr 2023 03:55:00 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1B22A180211 for ; Thu, 20 Apr 2023 20:54:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 20 Apr 2023 20:54:57 -0700 (PDT) Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-771e0f8b541so263275241.0 for ; Thu, 20 Apr 2023 20:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682049296; x=1684641296; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=aoq5BQC+WZOWfTPT31Z3Oj4ZEflYMOuvtfQeh2spTV0=; b=HANjiQ8YPTLFjB5WBDBZP+nZMXZQRSdfs/SmegG6tBPWmdwDgyzKQ6h3W90aV0DxOF HLHdp6V3vtgEUHcz1tA7NqsbMfYkUSFLh0wRhm/S/JQSbYZypO9tngI+iFkGBy6ABvpp WauGw+0AsiuWdIQ1DH7Bg24JeCJ5bP4WcEVihqHejmHdEiE/HWQXriey8jnXXsx3y0+Q QOgAyLxnapq5ZPx/ax7EjGlm1OUGFkLDkZsMB5PYImz+tkNDGlz8E/wtlMjJzD1HHIw/ 5W8nGkbg0sS557KjPejDRCFT8MFLPzG8na/NKyHdK/9jjxgArWNHk1qiV1WYQr2X22gD ShYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682049296; x=1684641296; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=aoq5BQC+WZOWfTPT31Z3Oj4ZEflYMOuvtfQeh2spTV0=; b=cHU3u8qUjtcJvz0NLZ1Sw0QEo3MOPOoHSjyiB+8XopB1/j6+N9t6GMk1Nm7kyxIXRO GRaW+oaeFUU9V288QuUp9bwU0u+iAGbhLM+PDZsIhSNTddy6FJXu/+Pot8cKAvX7Yr6q SXMkBNvtozjFc6uGbjLCg0nJa1bHBQB6X4e9fRf1ePxDNmx4qcK/Iq8bgoW/UQ5rJFUh u2bDJL9jwoJ0n0Nn+8yUUyXaQ/nTbt/I7vcUBPEbVuvZJLR3fHjRI6y4ixp9TfZTX2Xl 0U5rClLicyUjRW+oA4900BJvaqSixJKooTr8ju5Bm7f15ElslsIcUlpYwucKeZKVuIul 04Gg== X-Gm-Message-State: AAQBX9c/lyTUpDRChLUFNzf6MzEBKGkupvFGKUaa1ECiVxOcxrvKVLPi yXfUZBkxpKO6fEEU67YkaRoBoMv51ktzhKKBxEHEDqk+hgdGMw== X-Google-Smtp-Source: AKy350bOV4QLs2ut3cXhCF7EwtGgxLnawchGDOvCWEky7Tln7YdjiTxDc6UAJ4pfzx9V51PDeWXKf+r/e+MAdhHZD5I= X-Received: by 2002:a05:6102:3c9a:b0:430:808:64f4 with SMTP id c26-20020a0561023c9a00b00430080864f4mr1924909vsv.1.1682049296233; Thu, 20 Apr 2023 20:54:56 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 21 Apr 2023 00:54:20 -0300 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000cbf9c605f9d09e89" Subject: Expansion of PHP Symbols? From: deleugyn@gmail.com (Deleu) --000000000000cbf9c605f9d09e89 Content-Type: text/plain; charset="UTF-8" Hi Internals, sorry for the potential long email, but I can't sleep and I want to dump this out of my brain. Just a quick intro, let's recap PHP simple nature with this index.php file: ``` it immediately sidetracks into "how do we make that less fugly to write, > because callable types are naturally very verbose?" That leads directly to > typedefs/type aliases, which take one of two forms: type TwoInts = callable(int $x, int $y): int > type LinkedResponse = ResponseInterface&LinkCollectionInterface > which raises autoloading questions and means a dependency on a type > defined in another package, in many cases Here I want to raise the discussion about the little I know about PHP symbols. If a symbol `interface Foo` is discovered and registered by PHP, it will be usable as an interface throughout its entire execution. If the symbol is not discovered and is used, it will trigger autoloading as a last-chance before fatal error. Can `type Number = int|number;` be a symbol? Can `type TwoInts = callable(int $x, int $y): int;` be a symbol? and lastly, can `function bar() {}` be a symbol? Here is how I see that unfolding: file-1.php ``` ``` file-2.php ``` ``` file-3.php ``` ``` How do we solve this? - Include/Require - Custom Autoloading - Composer/PSR-4 Sounds familiar? PHP already has a namespace to solve for grouping of types such that `\Foo\Bar` and `\Bar\Bar` can already co-exist because they are two different symbols. We already rely on classes/interfaces/enums defined on third-party packages, why not make type aliases work the same? And if functions could be symbols, it would work out the same as well. One limitation I see is that symbols cannot have conflicts. Enum/Interfaces/Classes cannot be named exactly the same under the exact same namespace. Type Alias would follow the same limitation. Function would be able to escape one part of that limitation if the engine could prefix every function name with `f_` or `fn_` when registering its symbol, making it backward compatible and allowing `class Foo` and `function Foo` co-exist, but not two functions called `Foo` (which is already an error anyway). Now one questionable user experience I see is defining: - 1 Class = 1 File - 1 Interface = 1 File - 1 Enum = 1 File (this is already annoying) - 1 function = 1 file - 1 symbol = 1 file But this user experience does not come from PHP's nature, but instead it comes from Composer/PSR-4 because PSR-4 maps namespaces to directories and symbols to files. We need a static analyser to scan our entire project, discover every symbol and create a mapping such as: - Symbol Class_Foo -> x.php - Symbol Interface_Bar -> x.php - Symbol Enum_Options -> y.php - Symbol Enum_ExtraOptions -> y.php - Symbol fn_foo -> z.php so that our registered autoload can include/require the necessary file when the symbol triggers an autoload. This static analyser already exists and is called `composer dump-autoload`. It just has not implemented a PSR-X which allows for this pattern? In conclusion PHP Scripts are very simple and dummy things and it already has a limitation of symbol discovery. We have already built tools to work with that limitation around autoloading/psr/composer. We could extend the PHP Symbol system to include functions and type alises. If this can be done in a backward-compatible manner, we can already integrate those into PSR-4 from day one. Lastly, we lift the social-construct limitation of 1 file = 1 symbol with PSR and Composer since PHP never really had this limitation built-in. We come out of it with 3 major wins (from my pov): - Function autoloading - Type Aliasing - Never creating 3 files for 3 Enums again If you managed to read up to here, I apologize for late confessing I know nearly nothing about PHP internals codebase. Is this obviously wrong and am I just hallucinating a new awesome PHP version here? -- Marco Deleu --000000000000cbf9c605f9d09e89--