Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125042 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 1547E1A00BD for ; Sun, 18 Aug 2024 09:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1723973942; bh=7DnyiLZl7qV0jeu9ZBF9/YcuB92eLQiVDafxupMTW/A=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ScKhgzcLe/G+CljB0h9GSNzoMU4HpuhfyPdPCkCYQ3Vxvq1GB4ZQB26wBWiOmyVIT HX5FomcIZuTwWwpujcrQikeMRUos5VdgqsdoaKy5kKPBdclnbDYoAXh5YQ+VLCtl90 n+FeKLCHX0jD9aKRdV3dHqNGEehvSUhs6YKf/TtdC/W6oWsbY2Ra7u5t4EYCXAkuri nPgnK9HAi1FntkjNkV8tWohrJNBafEIHlgaLCdP9G0qII7FrqGAo82YFqxzuxbv5Km T0kou1KbE1pXqD6fG11TpWf0/z+k0pV22NtWhJhZ7EV4GEO4jB6MYrWa8OisGbIg7O oyc27woPsS60g== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DEC20180071 for ; Sun, 18 Aug 2024 09:39:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DMARC_MISSING, HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 18 Aug 2024 09:39:01 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.244.194]) by mail1.25mail.st (Postfix) with ESMTPSA id A53D4604C3; Sun, 18 Aug 2024 09:37:06 +0000 (UTC) Message-ID: <44486322-F313-405C-91D0-EA13FCAD9C65@koalephant.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6D1E4BF2-3C4D-4759-99BF-67104707095E" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: [PHP-DEV] function autoloading v4 RFC Date: Sun, 18 Aug 2024 16:36:53 +0700 In-Reply-To: Cc: PHP internals To: Rob Landers References: <94259551-80EE-41F4-9CF9-679B79B5EA49@koalephant.com> X-Mailer: Apple Mail (2.3776.700.51) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_6D1E4BF2-3C4D-4759-99BF-67104707095E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rob, > On 18 Aug 2024, at 04:33, Rob Landers wrote: >=20 > I wouldn't consider it a BC break, no. But (ironically?), Symfony = crashes with this change. I wasn't aware of that specific code before but it's exactly the type of = issue I was talking about earlier. > Ah, good catch. I've updated this and gone through other relevant = functions. The RFC now says "The spl_autoload function will not be updated.", but = that will *also* break if it isn't updated to at least *account for*, = even if it doesn't *use* the second argument given. However I'm also curious why you would *specifically* make it *not* = support function loading? The current implementation should work unmodified, once the signature is = changed to accept an int as the second parameter (and move the current = 2nd parameter to 3rd), There is nothing "class specific" in the = existing implementation except for a couple of variable names. I would imagine you also need to update spl_autoload_unregister[1] - it = also needs to be able to identify the type of autoloader it's operating = on (because the same autoloader might be defined for both types). And lastly I think you'd need to adapt spl_autoload_functions[2] too - = perhaps the same as the others, introduce a parameter `int $type =3D = SPL_AUTOLOAD_CLASS`, so existing code works as-is, otherwise it'd be = impossible to know how a given autoloader was registered. 1: https://www.php.net/manual/en/function.spl-autoload-unregister.php 2: https://www.php.net/manual/en/function.spl-autoload-functions.php Cheers Stephen=20= --Apple-Mail=_6D1E4BF2-3C4D-4759-99BF-67104707095E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Rob,

On 18 Aug 2024, = at 04:33, Rob Landers <rob@bottled.codes> wrote:

I = wouldn't consider it a BC break, no. But (ironically?), Symfony crashes = with this = change.


I wasn't = aware of that specific code before but it's exactly the type of issue I = was talking about earlier.

Ah, good catch. I've updated this and gone through other = relevant functions.

The RFC now says "The spl_autoload = function will not be updated.", but that will *also* break if it isn't = updated to at least *account for*, even if it doesn't *use* the second = argument given.

However I'm also curious why = you would *specifically* make it *not* support function = loading?
The current implementation should work unmodified, = once the signature is changed to accept an int as the second parameter = (and move the current 2nd parameter to 3rd),  There is nothing = "class specific" in the existing implementation except for a couple of = variable names.


I would imagine = you also need to update spl_autoload_unregister[1] - it also needs to be = able to identify the type of autoloader it's operating on (because the = same autoloader might be defined for both = types).

And lastly I think you'd need to adapt = spl_autoload_functions[2] too - perhaps the same as the others, = introduce a parameter `int $type =3D SPL_AUTOLOAD_CLASS`, so existing = code works as-is, otherwise it'd be impossible to know how a given = autoloader was = registered.