Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119913 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 74248 invoked from network); 11 Apr 2023 12:33:13 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 11 Apr 2023 12:33:13 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E8D7B180506 for ; Tue, 11 Apr 2023 05:33:09 -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=-0.5 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE, 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-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (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 ; Tue, 11 Apr 2023 05:33:09 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id dm2so20026920ejc.8 for ; Tue, 11 Apr 2023 05:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20210112.gappssmtp.com; s=20210112; t=1681216388; x=1683808388; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=n6Uh6/Vnb9garP52sLhW88kl7NuJsrTTvG2R9oUUw3c=; b=68sdwo9OkxSfsDW5XVqBYJ+UJ2mcBhNDRQwNJdtZ7qPJsXkoqrp/X1zUaibR7iPhTL q/Ct6cW7rhfk6nVoL9DwpowhVwT6f/+1FFKYOa6s9w5YaZPP73ecWGd3lyS3SeBOezmA oSN6QIdy7WVL0P/+O5xhpiS58gn9Q5zq4PtLSJQLxNqzCHexo7q7l0ZmN6edt9vc3f0G CP26KXRh9NJov7cQ1DtsbHUWupJ+0P6zl0xnjbk4GqRKTtDGrpkvLXTcJO3/9yrhfN27 UQYzeTiWj7nHhK5awBoKnVlTuyueWnwMkOyxVNcmzMVdcrAnO13ATpY1qVLov4wCGbN5 tcgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681216388; x=1683808388; h=content-transfer-encoding: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=n6Uh6/Vnb9garP52sLhW88kl7NuJsrTTvG2R9oUUw3c=; b=O2gsMr+d2hPEfv7vUrs6XMB5jx0bAL4fz/bdwkLeIcYuCHbQ4ykgwAtoWXxJ28tBB3 KYXKoJ4x+nB624ZEWucOoXwSTLuisZ/uiYbJo04h9GqcG0p1ezTADgwA8T9ryjVw9yQe 7nPAg1+N3s+Z1Em1e7dqReXdHxBqp5J4Qd7D9BAfBLG5lTXq/L3VOV8+r6oPeCvGoJhr Z2uV3ka3WuTFFrxHoQ7MZM7dns7Xs1p0Xm7jXuOzdOMWAujtNYWZLl1GlxVEREWF+3KI 3LxxBuvr/Vp/u8B+3a8qwOUbCiJ51EPcw71Czhee5Kuz+F3w6frhPKDnqGAjD0C1uPzj 5Ysg== X-Gm-Message-State: AAQBX9cw12NNnHY6E13kawl+NWrdLwR+QelfB6IrkMxpe/37Q1KIrABI GAKTKnEIvVjSktYv87edXL7LSj85rfHAlM/4PDSd7A== X-Google-Smtp-Source: AKy350arQcf1UtvBoX8GiFj9IXQ3jTXsXpIeX+eu83Fg5ehq9VXybhgOibmaQ+LcugMHVXXsIyrYnrACoiDlMtAN1uk= X-Received: by 2002:a17:907:74b:b0:8af:43c6:10c0 with SMTP id xc11-20020a170907074b00b008af43c610c0mr5371310ejb.1.1681216388365; Tue, 11 Apr 2023 05:33:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 11 Apr 2023 13:32:57 +0100 Message-ID: To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= Cc: "G. P. B." , PHP internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading From: Danack@basereality.com (Dan Ackroyd) On Tue, 11 Apr 2023 at 08:14, Micha=C5=82 Marcin Brzuchalski wrote: > > Can we improve the RFC with a short description of issues on SPL autoload > this RFC tries to address? Sure, if you want to propose some clearer words than these: "The spl_autoload_register() does not become an alias for autoload_register_class() to preserve BC by continuing to return true, allowing it to register the default SPL autoloader, and accepting the ignored second parameter, but they are both forwarded to an identical internal implementation." The RFC could always be improved. But the main reason to separate the autoload functions from the SPL, is that imo autoloading probably should never have been part of SPL. At the time, new functionality was dumped into SPL as a convenient place to put stuff. At some point (probably after distributing extensions becomes a lot easier) moving the SPL away from PHP core might be a sensible thing to do, as the SPL has some 'not great' design choices that are pretty impossible to solve: https://phpopendocs.com/rfc_codex/spl_summary Or at least impossible to solve while the release cycle of the SPL is tied to that of PHP itself. But autoloading would need to stay as part of PHP core itself. cheers Dan Ack