Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120105 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9112 invoked from network); 21 Apr 2023 15:13:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Apr 2023 15:13:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 05D37180211 for ; Fri, 21 Apr 2023 08:13:37 -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-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 ; Fri, 21 Apr 2023 08:13:36 -0700 (PDT) Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-771ef819305so99857241.1 for ; Fri, 21 Apr 2023 08:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682090015; x=1684682015; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=biAX8t02nGdKJC2nuCvYJ+7B9yUmMiOwi1OCcz5apfM=; b=qApNPe424oM6SjYN4Gborcw5nyNjfaf6quLLlQ6AEVGWVATilQt39pBKrtghz8Jrq3 QPdsFinlfOuIp//E1TisIMznI1lAjQQPOqn8Urxik/95WzmpWEQQ+MzOB9xlhs7E85zM AI4DbIV5LOxRwNbzGvenG0WawJ2G9RDFcdrdlBG5W9A3XuZoWeFQ/GwtJqinbqOXw64n ovbbO9GIDiewoL73F3/fhxZ/fR0coCkqQYyVC8jX0sdSZHnqfHyO+yiG9iXa74c105VH jDdCnBGQzbL3Bng7m2y/cgrdX7R5kJhlWqOoEI9JWaiKtUaNG3ceblmcm7QXB9/npBu+ 8apg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682090015; x=1684682015; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=biAX8t02nGdKJC2nuCvYJ+7B9yUmMiOwi1OCcz5apfM=; b=SVxXZiKFZDQABj8v8GTug3dtM4QEyr8+OhGBLVgj+2rt2EqXKF992d1Allc+umsE0A kpuZbq5JjR0WZJNnLzwCFSuCPAk0F92st/Hg25pDDrRprNwhnQXun4ISgNe3kEul/lDq jxRLfEk+3TjoSs/8G8ltlEOey5U81xfxvXSA5NmZOfN0vct3v5jWHP/j7M6pholohcLA wRz4Y8TgqC4CpxnH/NDhrlLHM3o7HIbDW3qMdx7ZmHz05QKRrE0od1lAxMvtyAyypdPX iWlCYGttV6YTFRku4g1usre7Cta0xVvPoWoqUFJ76cJZ/szov15TpPVxRzsP6jsiIdcC NH9g== X-Gm-Message-State: AAQBX9erKdTM2+eapZ5QOzMFNyfJHFOKXClkGVwlyj5kZ6QoKMUscX1k GpvU9v8/yGCdR8qT4og29RZzUFcK6OrZ1BAFRtKj31eI5Qk= X-Google-Smtp-Source: AKy350Znq4Aq0KBOOSTlPjSIRd43wcMCYUUzvcS2QKBNzkEb7zg1eUta5egDOhuCj4odEtsUQFYHy/30FhksOviKFRA= X-Received: by 2002:a1f:a845:0:b0:443:e276:1b22 with SMTP id r66-20020a1fa845000000b00443e2761b22mr1917785vke.0.1682090015436; Fri, 21 Apr 2023 08:13:35 -0700 (PDT) MIME-Version: 1.0 References: <6581c252-75c9-889d-75d2-eff5220216c2@gmail.com> <8fa3e835-41b8-4f57-aa9d-4fe0ac584766@app.fastmail.com> In-Reply-To: <8fa3e835-41b8-4f57-aa9d-4fe0ac584766@app.fastmail.com> Date: Fri, 21 Apr 2023 12:12:59 -0300 Message-ID: To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000d9b47305f9da192f" Subject: Re: [PHP-DEV] Expansion of PHP Symbols? From: deleugyn@gmail.com (Deleu) --000000000000d9b47305f9da192f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 21, 2023 at 11:18=E2=80=AFAM Larry Garfield wrote: > To piggyback on this point and go deeper into the "Composer/PSR-4" part: > > PSR-4 (and PSR-0 before it) are just standard rule for mapping a class > name to a file. The intent is that an arbitrary autoloader written by > anyone can then "find" classes from any package. PSR-0 came out in 2009. > > Composer came out in ~2012. It actually has four different loading > mechanisms: PSR-0, PSR-4, "one big lookup map", and "files". > > PSR-0 and PSR-4 use those specs' class-name-to-file-name translation rule= s > to look up a file on the fly. > > The "one big lookup map" scans the entire code base at dump time and > builds up a big table of where every class-like is. Whether it conforms = to > PSR-4 or not is irrelevant. Then at runtime it just does an array lookup= . > I've many times run into the "fun" situation where a class was not proper= ly > named per PSR-4, but because the autoloader was set to auto-dump always, = it > never caused an issue as the built-map still worked! (Until it didn't, o= f > course, because the lookup table is a cache that can get out of sync and > give you no helpful error messages about it. I've lost much time this way= .) > > And the "files" approach just greedily includes those files as soon as > Composer initializes, and lets PHP take it from there. It's not even usi= ng > an "autoloader" at all. > > (Fun fact: In Drupal 7, in the pre-PSR days, we built our own autoloader > that worked on a "register and scan" model and stored a lookup table in t= he > database. It... was not the best code I've ever written, but it did work > for many years, and it's still running in the millions of Drupal 7 sites > that still exist. For Drupal 8 we, thankfully, switched to Composer as t= he > autoloader.) > > I've long felt that the advent of universal opcache usage and preloading > (although few people use the latter, sadly) means that leveraging "files" > should be a lot more popular than it is. That's what I do for my > functional code (in Crell/fp); I just "files" include everything (which i= s > admittedly not much) and move on with life. PHP is a lot faster at this > than it once was. > > It's also why I'm only kind of luke warm on function autoloading. I'm no= t > against it, but I don't see it as the blocker to more functional code tha= t > it once was. And as noted, how the heck do you then organize your > functions so they're autoloadable? One per file is silly. So now we nee= d > to build some kind of map, and... we're back to the "one big lookkup map" > approach, or something. > > I think there's still a lot of cultural aversion to front-loading code > from the days when it was a lot more costly. PSR-4 is very good for what > it is, but it's not the final word on code organization. It doesn't have > to be treated that way, and that's a change that requires no core code > changes. > > If we actually got working shared typedefs in the language, TBH I'd > probably recommend people put all of their package's defs in a single fil= e, > "file" load it with Composer, and move on. Don't even bring PSR-4 into t= he > picture. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hey thanks for the reply. I just want to go an extra mile to make my points clearer. Please take no negative connotation from what I posted towards Composer, PSR-0, PSR-4 or such. I was merely describing things from an end-user perspective to bring everything I think about into context. My simplistic and naive view of things come from reading about typed callables, function autoloading and type aliases. My biggest question is still understanding what is fundamentally different between `class Bar` and `type Foo =3D Bar|Baz`. I understand that the current state of things in th= e PHP world, folks will likely hate declaring 1 type =3D 1 file to conform wi= th PSR-4, but that has nothing to do with the engine - it's not good nor bad for the PHP engine and just extends on an extremely well defined existing principle of PHP symbols. The recursive resolution of function autoloading does explain a little bit why it has been controversial and a final decision has not come out of it yet, but even there it's just a matter of whether consensus can be achieved that a combination of PHP Engine + Community work can bring to a great final state and not every detail needs to be burdened on internals. At the end of the day I would love to declare a few functions on a single file, a few enums on another file, a few type aliases on another file and perhaps even a few intertwined/related small classes on the same file. PHP Autoloading functionality is 90% there and we would just need function autoloading, type aliases definition and PSR-X + Composer static symbol scanner (something that seems to already exist?) to make it a great developer experience. If you don't use Composer, nothing gets worse (except maybe function autoloading + performance), but if you use composer already, this can be a seamless transition and perhaps even bring more interest towards preloading. To maybe beat up more on function autoloading, if I understand correctly the current open proposal sidesteps the performance impact by making function autoloading a "separate autoloading filtered by type" kind of mechanism. If you upgrade from PHP 8.x to 8.x+1 with no code changes, your performance impact is zero. Your first performance impact arises when you register a function autoloading (making it opt-in) & then you can choose to opt-in by using a strategy that perhaps allows you to fade away the performance impact with the Composer Static Scanner dumping mechanism. I feel like this all sounds too good to be true/possible because if it were easy, it would maybe have been done by now. Even if we park function autoloading altogether (for its controversy) and focus just on type aliases, the question remains: Why is it not possible to make Type Alias the same way that Enum was recently introduced? --=20 Marco Deleu --000000000000d9b47305f9da192f--