Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125126 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 B20F41ADAFC for ; Fri, 23 Aug 2024 11:52:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724414040; bh=qFjdWZkzfhGd9N6nt2jAcVjGXO9uk2YCucP2O+CbIbM=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=i5/yPiIeXgYm9wwSobAwqkfUcle9HyNdwG+vjLGyYs3uH9ftESk/CHe1Tf11dVjRs ZuEKh95GzCZ8QKRxURwVkONRYWcVkLos0xNYMm1Q3qkhqbkuRvR22wpjxy6Ik2UWqf Kmy06v5RHSXOzwQQ7NHqTIfUB1yZyNlVYn3VgeARcKSNYqvxTcrTj4YEx3PiP6XI6F eIbo1ihVBnhh/4qwt26LR6KDg7BlYDKT4EA2XOiNXIeuf+AMsAfVGN0rstOu9vEcXF pRYyVhIC6ZaEGG9iLBJFCa7VoUzu93VdIBcVkSHZxtjmHPlx9Om+mIqo/Tw7zH/46W 3mR3VaFw4Nlsw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8B3A31801E0 for ; Fri, 23 Aug 2024 11:53:57 +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,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 23 Aug 2024 11:53:55 +0000 (UTC) Received: by mail-yb1-f172.google.com with SMTP id 3f1490d57ef6-e03caab48a2so1483381276.1 for ; Fri, 23 Aug 2024 04:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1724413924; x=1725018724; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=jvVWnskSXKD6A7kT71e4iAmbsfZpJrWc7vvsiGzcsCQ=; b=A+CbxPl3sQ59le9o23YiHVQ8JAdEk2LsEti9ps8cP8aqoEwCtUSKHh92MWExxn7h12 Z98bzSgWq98TOf6XSm+z31gyrlzJSzrZ5rYn/K7/A6R888IEmNIS5MVhwdEP4x26tIYm 65F7dV7CULz7zsgifrHRC5YpkK9lwl0UCe+vrfh3JaXwZ2ESu5AeycsCLyKW87PB7z0c VRX1VQhH0/Vzf+F6ifi/vmPGYcL/vbYD4j/+HgxtWsxVita+CqxJ+i6OLbjOcxBSKbM9 /MjiX9KKpa82FqnFkQKvCtB/swezMhbNGXnTiOCEAYswbUXhZGeW5jFIkn2lIjKmDgOz LQpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724413924; x=1725018724; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jvVWnskSXKD6A7kT71e4iAmbsfZpJrWc7vvsiGzcsCQ=; b=lC5sunBhMreNn82XenyzbvlEU5e7SmLT8EK8FRPO491Zw5e2zStBE1UfYaw2rgFZ6Y PSMSsybmACwpdg6dzsJZ0wqyxIe2TG9dIx+pxaJ+QdzaJrqn8I1qHYdmtkPq4KSFy6AK qupSlAaIzUbQLHz9KbAFmzzmG/AGwfgC/DZ2FqY44YjeoHza/sgkznEpOMOcOyzUzQs7 fF9twdAs4i6Usjf+qTHgMqzXLx5Z03+VTIPlIayMmydC2whxBzmVuC4sOQxm1P5PEd8n 1gnw4xBxaHzVvbPEDGY0tYFdSG9s4VGSpx/HZZqgffHJCwslmFYoCBqo/vNGQQw84cTz WZ5Q== X-Gm-Message-State: AOJu0YwiM5DSNF2Z3nOZQ8F31onoIW8o6gaB1xExFFK9H431fAi4XelQ pJTGlJ7R6YlujIPsQOwp26+LRv0Cd9NUoFOT5uU+dBXfEkhSbbOHMqasB4flJZ1Yzv1/VNtR7M3 Rjkw= X-Google-Smtp-Source: AGHT+IEz7xH18u/SdC8B+ZkqvN6eBJzbBZt3cZ37mmsbqol98dOvEsRGSA0qcrxM+WTUcPuncOqS0A== X-Received: by 2002:a05:6902:2e88:b0:e0e:ce2c:c287 with SMTP id 3f1490d57ef6-e177e0ca549mr5727886276.19.1724413923530; Fri, 23 Aug 2024 04:52:03 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e178e43fc8dsm627074276.6.2024.08.23.04.52.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2024 04:52:01 -0700 (PDT) Message-ID: <5A8049C2-47E2-4B11-89E7-B9195DBDC7B3@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_23745391-099E-4893-A4A9-915014AFE277" 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 \(3696.120.41.1.8\)) Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local) Date: Fri, 23 Aug 2024 07:52:01 -0400 In-Reply-To: Cc: internals@lists.php.net To: Nick Lockheart References: <846D7756-712B-4A7C-9FC6-DB9F858836B8@rwec.co.uk> <880ffc27dc9b421407a670c75d5f5ba756870396.camel@ageofdream.com> <790534cd-e158-4712-878c-642dfd0e2bad@app.fastmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_23745391-099E-4893-A4A9-915014AFE277 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 23, 2024, at 4:08 AM, Nick Lockheart = 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. >=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. I was going back and forth on this. On one hand it could be confusing for developers to learn when to use = `\` and when not to. OTOH, once they learn it would create a clear indication of which = functions are userland code and which are standard library, and I this = could have significant benefit for readability and maintainability. Yet OTOH, this would create a bifurcation between userland and standard = library that is encouraged in some languages and discouraged in others, = i.e. the latter being the "keep the language as small as possible and = then let the standard library be implemented in the language no = differently than any code a user could write" type of languages. =20 Yet OTOH still, PHP does not allow core functions to be implemented in = userland, at least without monkey patching so the bifurcation already = exists.=20 Go, for example, has both. Most of the standard library is just Go code = anyone could replace with their own, but a handful of functions are = special and built into the language, e.g. append, new, close, etc. = Basically anything in lowercase that can be used globally without = qualification is special. And after using Go, I think it is a great = design as it reserves future enhancements without BC concerns. In theory it would be nice to open up PHP to allow overriding core = functions, but that could also open a Pandora's box, the kind that makes = Ruby code so fragile. At least in Go you have to omit the standard lib = import and use your own import to override a standard library package. So in practice PHP may never change to allow core functions to be = overridden and thus pining for that to block this idea would be a missed = opportunity. (That said, PHP could allow a userland function to be = "registered" to be called instead of the core function, and if that were = allowed then Nick's proposal would cause no problems. Of course I doubt = internals would ever bless that idea.) =20 Anyway =E2=80=94 in summary =E2=80=94 I think Nick's 3rd option has = wings. And along with automatic `use` statements for each namespace = might just be the best possible solution. -Mike P.S. If PHP ever added a set of standard library functions written in = PHP to the core distribution, they should rightly IMO need to be = namespaced, per this proposal. But here I digress. I only mention in = hopes to keep this specific dream alive for some future day. --Apple-Mail=_23745391-099E-4893-A4A9-915014AFE277 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Aug 23, 2024, at 4:08 AM, 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.

I was going back and forth on this.

On one hand it could be = confusing for developers to learn when to use `\` and when not = to.

OTOH, once = they learn it would create a clear indication of which functions are = userland code and which are standard library, and I this could have = significant benefit for readability and maintainability.

Yet OTOH, this would = create a bifurcation between userland and standard library that is = encouraged in some languages and discouraged in others, i.e. the latter = being the "keep the language as small as possible and then let the = standard library be implemented in the language no differently than any = code a user could write" type of languages.  

Yet OTOH still, PHP does = not allow core functions to be implemented in userland, at least without = monkey patching so the bifurcation already exists. 

Go, for example, has = both. Most of the standard library is just Go code anyone could replace = with their own, but a handful of functions are special and built into = the language, e.g. append, new, close, etc.  Basically anything in = lowercase that can be used globally without qualification is special. = And after using Go, I think it is a great design as it reserves future = enhancements without BC concerns.

In theory it would be nice to open up = PHP to allow overriding core functions, but that could also open a = Pandora's box, the kind that makes Ruby code so fragile. At least in Go = you have to omit the standard lib import and use your own import to = override a standard library package.

So in practice PHP may never change to = allow core functions to be overridden and thus pining for that to block = this idea would be a missed opportunity. (That said, PHP could allow a = userland function to be "registered" to be called instead of the core = function, and if that were allowed then Nick's proposal would cause no = problems. Of course I doubt internals would ever bless that idea.) =  

Anyway = =E2=80=94 in summary =E2=80=94 I think Nick's 3rd option has wings. And = along with automatic `use` statements for each namespace might just be = the best possible solution.

-Mike

P.S. If PHP ever added a set of standard library functions = written in PHP to the core distribution, they should rightly IMO need to = be namespaced, per this proposal. But here I digress. I only mention in = hopes to keep this specific dream alive for some future day.


= --Apple-Mail=_23745391-099E-4893-A4A9-915014AFE277--