Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125139 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 A751B1A00BD for ; Fri, 23 Aug 2024 13:19:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724419265; bh=TiV4hYWTC1RtrUzQ2rQpcA+L9KlReU/k40oYnV0bhaM=; h=From:Subject:Date:References:To:In-Reply-To:From; b=dK8TiF7NrqxRNXIQFmrrpapkS9FwBfgW3zX5tWAc7zXCVwkL6Z52yF6O/oCUxPc+k Wzp/KbrIJ5nSnWHuXYail9UpfYRjLD8xVbVMXhrbQbwrYPMG7aHc5rGG+oLmfYFbax fr5O8xlMVX6sEu3VHX4qy5K+nyNGx0ce+7kIcFIl7+qn+SHbvJaPaNHnKu843juiFr RAGKH3xYiNQH4rXNjDxNQvk9KYEgPeuxsGJbwTR8nMWWibO5ZMXaBNu6mSOGl61RNz tvXILV1R3NHYmwFy140t5YSC7P6VGr/dRY0dq/fgDjqund1xG9xxw25rAxUsCQgBKT Y8pcUscuEG0kA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6145A180054 for ; Fri, 23 Aug 2024 13:21:03 +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 ; Fri, 23 Aug 2024 13:20:59 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.221.224]) by mail1.25mail.st (Postfix) with ESMTPSA id ABA5D60404; Fri, 23 Aug 2024 13:19:03 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_D8C23E74-EED8-4D1E-93A4-C6C8A2162F75" 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] [Concept] Flip relative function lookup order (global, then local) Date: Fri, 23 Aug 2024 20:18:50 +0700 References: <846D7756-712B-4A7C-9FC6-DB9F858836B8@rwec.co.uk> <880ffc27dc9b421407a670c75d5f5ba756870396.camel@ageofdream.com> <790534cd-e158-4712-878c-642dfd0e2bad@app.fastmail.com> To: PHP internals , Nick Lockheart In-Reply-To: Message-ID: <1FC19A96-0CCA-4FF8-8F2E-CC228BE45AFE@koalephant.com> X-Mailer: Apple Mail (2.3776.700.51) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_D8C23E74-EED8-4D1E-93A4-C6C8A2162F75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23 Aug 2024, at 15:08, Nick Lockheart wrote: >=20 > A third option, which I haven't seen come up on the list yet, is that > unqualified functions that are PHP built-ins are treated as global, = and > using a function having the same name as a built-in, in a namespace > scope, requires a fully qualified name to override the built-in. >=20 > It seems that if someone is writing `array_key_exists()` or similar > they probably mean the built-in function, and in the rare cases where > they do mean `\foo\array_key_exists()`, they can write it explicitly. >=20 > Functions that are *not* on the built-in function list could default = to > the local namespace. This doesn't solve the "future hidden BC break" aspect, at all. If I write a namespaced function `http_parse_url` to adhere more = strictly to whatever relevant RFC, when I write it, it will work as = expected using a relative name (and/or itself quite likely using helper = functions in the same namespace) If an RFC then approves a "core" `http_parse_url` function to serve as a = better replacement for the old `parse_url`, suddenly my function won't = work the same way with the new version of PHP... because of a global = function that didn't exist when I wrote mine. If this "global first" change is made, *any* use of unqualified = functions that refer to the current namespace will *have* to use some = form of current-namespace indicator to be future version-safe. If you want to make global functions resolve without a `\` the only = realistically safe solution is to completely remove unqualified lookup = of local function (and constant) symbols, and force them to always use a = name that resolves absolutely, because otherwise any future version = could break what they do completely. --Apple-Mail=_D8C23E74-EED8-4D1E-93A4-C6C8A2162F75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 23 Aug 2024, at 15:08, Nick Lockheart = <lists@ageofdream.com> wrote:

A third = option, which I haven't seen come up on the list yet, is that
unqualified functions that are PHP = built-ins are treated as global, and
using a = function having the same name as a built-in, in a namespace
scope, requires a fully qualified name to = override the built-in.

It = seems that if someone is writing `array_key_exists()` or = similar
they probably mean the = built-in function, and in the rare cases where
they do mean `\foo\array_key_exists()`, = they can write it explicitly.

Functions that are *not* on the built-in function list = could default to
the = local = namespace.


This = doesn't solve the "future hidden BC break" aspect, at = all.

If I write a namespaced function = `http_parse_url` to adhere more strictly to whatever relevant RFC, when = I write it, it will work as expected using a relative name (and/or = itself quite likely using helper functions in the same = namespace)

If an RFC then approves a "core" = `http_parse_url` function to serve as a better = replacement for the old `parse_url`, suddenly my function won't work the = same way with the new version of PHP... because of a global function = that didn't exist when I wrote mine.

If this = "global first" change is made, *any* use of unqualified functions that = refer to the current namespace will *have* to use some form of = current-namespace indicator to be future = version-safe.

If you want to make global = functions resolve without a `\` the only realistically safe solution is = to completely remove unqualified lookup of local function (and constant) = symbols, and force them to always use a name that resolves absolutely, = because otherwise any future version could break what they do = completely.


= --Apple-Mail=_D8C23E74-EED8-4D1E-93A4-C6C8A2162F75--