Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125164 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 E34E71A00BD for ; Fri, 23 Aug 2024 19:28:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724441416; bh=ds29sYonk06Ohd9YYhngZ0UspoxEsmWM7LHDeF0IIlk=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=AHrBbyPnRafJA6YP6I0nnmPhTSZoQY+bpSK0+FrsecKdZf6I4OIG5AXoM5usUitnX uGalgDNdleYBKB4tt6CFKyBuQbMPZbdazvZU5jMUAM9W1yXkDy028j6j5tODw2C3WT G1+ksJuieElrV+goJ7ZKvbapXK3pzGNNCekexnvK6vZz0ZDpgbxi1rv3r9PV8LHr3K frli9uC+rVKhGksqweZW4NXFR42f9yfC0Zgf69h6YH/73aVWZluG5AbiiRvX6Y/fMJ iMmeQJvvQk5cexduhFlON8vOZAPcf4gNxQLfOJq9CI5q0/atm1Ktr1CBRupZlBbtLQ f1q40zWa+HOyQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1B2391806BE for ; Fri, 23 Aug 2024 19:30:15 +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.9 required=5.0 tests=BAYES_50,DMARC_MISSING, HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,TRACKER_ID 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 19:30:14 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.221.224]) by mail1.25mail.st (Postfix) with ESMTPSA id EB9DD6054D; Fri, 23 Aug 2024 19:28:14 +0000 (UTC) Message-ID: <67CD7F19-EDE5-4EA8-A1F6-60151691E76D@koalephant.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7C8306C7-ABA9-4B14-B325-054285BF6A73" 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: Sat, 24 Aug 2024 02:28:01 +0700 In-Reply-To: <931B9F3E-6630-4F6A-9822-1BAC81F0643A@getmailspring.com> Cc: "Rowan Tommins [IMSoP]" , PHP internals To: John Coggeshall References: <6C127753-4AA4-424A-BCD4-BD4CA6FA1DB3@koalephant.com> <931B9F3E-6630-4F6A-9822-1BAC81F0643A@getmailspring.com> X-Mailer: Apple Mail (2.3776.700.51) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_7C8306C7-ABA9-4B14-B325-054285BF6A73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 24 Aug 2024, at 01:37, John Coggeshall wrote: >=20 >=20 >=20 > On Aug 23 2024, at 1:46 pm, Stephen Reay = wrote: >=20 >=20 > The claims about "security" because a function you defined (or = included via a package) is resolved in place of a global one are = irrelevant. If you're including compromised code in your project, all = bets are off. >=20 > I have plenty of experience behind why I disagree with your dismissal = here, but I'm not going to debate it with you. >=20 If you're going to make a claim, but then refuse to back it up with any = kind of evidence when challenged, myself and most others are going to = ignore your claim, FYI. > BC breaks happen. While I am all for avoiding BC breaks when possible, = sometimes they make sense -- and I think this is a clear example of when = it does. >=20 > Please be specific what you mean by "this". The original proposal by = Ilija provides a constant BC break over time, whenever a new global = function is introduced. >=20 > I don't think we're piling in functions all the time here -- and = that's why we have deprecation notices when we do so we can warn users = to rename a conflicting function. >=20 How do you have a deprecation notice for a *new* function before it = exists? If you took this approach, any new global functions would have = to have an RFC and then wait until the next major version to actually be = implemented - so for example, str_contains, str_starts_with and = str_ends_with were all added in PHP8.0, back in 2020 - four years ago. = But because the RFC's were all conducted after the release of 7.4 (the = last 7.x release), none of those functions would be eligible to = introduce into the language yet, because a deprecation notice introduced = with 8.0 won't enforce it's warned change until 9.0, which we don't even = have a date for yet. Taking this approach, the following functions would currently still be = waiting in limbo for 9.0 to arrive and become available: str_contains str_starts_with str_ends_with get_debug_type fdiv array_is_list memory_reset_peak_usage ini_parse_quantity str_increment str_decrement stream_context_set_options And that's just considering the "standard" or "core" functions - if you = include extensions that are considered "core" there's a heap more. >=20 > Great, so 0.24% of public packages represented, and 0% of private code = represented. That certainly seems representative. >=20 > Honestly, statistically it actually is fairly meaningful and = representative. I have serious doubts if you went from 1000 to 10000 = you'd see much change (and would welcome that information if I'm wrong). >=20 >=20 > You've also missed the other aspect here, which I mentioned earlier: = namespaced function usage is low because the language hasn't = traditionally supported it anywhere near as well as namespaced classes. = There have been multiple people proclaiming recently that "static = utility classes" are the 'wrong' approach, that people should use = namespaced functions in their code. There are two active RFCs about = function autoloading. >=20 > This change would at best, make those functions slower to use within = the same namespace, and at worst, more work, with a brand new = inconsistency, to use within the same namespace. >=20 > The fact that functions have not been widely embraced as you argue = would be an argument for having this debate now, rather than later after = further adding to the complexity. That flies in the face of relatively common logic taken on most RFCs = these days, where potential impact on future features is a deliberate = consideration, so as *not* to negatively impact them, rather than an = attempt to "get in first" regardless of negative consequences down the = line. >=20 >=20 > The change we're talking about is in the range of maybe 2-4%, and is = 100% solvable in userland - and has been for those 15 years, in a way = that has zero impact on developers using the language to write their own = functions, and is consistent with the way other symbol lookups (e.g. = classes) work. I'll concede you one point. A footnote is clearly not = important enough for a 2% performance benefit. Let's make it the subtext = on the header of ever php.net page, just to make sure = people know. >=20 > By this logic we shouldn't have touched list , nor should we ever add = any functionality that can't be implemented in userspace using existing = tools. E.g. array_column=20 Are you referring to the `[$a, $b] =3D $array;` syntactic sugar? You = can't implement that in userland, and it didn't introduce any BC breaks, = so I don't see how it's relevant? array_column is considered to be = pretty common functionality, and the C version is about 5x faster than = the equivalent userland implementation (comparing against the polypill = the author of array_column provided) under php8.3, and was about 6x = faster under php5.5 when it was introduced. >=20 > I'm honestly not even sure where to begin here. If you add a = namespaced function to your code, and call it from within that = namespace, it will run. That's literally by design. If that is somehow = surprising to you, I'd suggest the aforementioned name resolution page = in the php manual. It's not exactly long, you can probably read it = quicker than this email. >=20 > You say it's by design, I say it's a bad design and should be fixed. Can you give an example of any other language where global symbols take = precedence over locally defined symbols of the same name?= --Apple-Mail=_7C8306C7-ABA9-4B14-B325-054285BF6A73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 24 Aug 2024, at 01:37, John Coggeshall = <john@coggeshall.org> wrote:



On Aug 23 2024, at 1:46 pm, Stephen = Reay <php-lists@koalephant.com> = wrote:


The claims about "security" = because a function you defined (or included via a package) is resolved = in place of a global one are irrelevant. If you're including compromised = code in your project, all bets are = off.

I have plenty of experience behind = why I disagree with your dismissal here, but I'm not going to debate it = with you.


If you're = going to make a claim, but then refuse to back it up with any kind of = evidence when challenged, myself and most others are going to ignore = your claim, FYI.

BC breaks = happen. While I am all for avoiding BC breaks when possible, sometimes = they make sense -- and I think this is a clear example of when it = does.

Please be = specific what you mean by "this". The original proposal by Ilija = provides a constant BC break over time, whenever a new global function = is introduced.

I don't think we're = piling in functions all the time here -- and that's why we have = deprecation notices when we do so we can warn users to rename a = conflicting = function.


How do you = have a deprecation notice for a *new* function before it exists? If you = took this approach, any new global functions would have to have an RFC = and then wait until the next major version to actually be implemented - = so for example, str_contains, str_starts_with and str_ends_with were all = added in PHP8.0, back in 2020 - four years ago. But because the RFC's = were all conducted after the release of 7.4 (the last 7.x release), none = of those functions would be eligible to introduce into the language yet, = because a deprecation notice introduced with 8.0 won't enforce it's = warned change until 9.0, which we don't even have a date for = yet.

Taking this approach, the following = functions would currently still be waiting in limbo for 9.0 to arrive = and become = available:

str_contains
str_starts_with=
str_ends_with
get_debug_type
fdiv
array_is_list
= memory_reset_peak_usage
ini_parse_quantity
str_in= crement
str_decrement
stream_context_set_options
=

And that's just considering the "standard" or "core" = functions - if you include extensions that are considered "core" there's = a heap more.


Great, so 0.24% = of public packages represented, and 0% of private code represented. That = certainly seems = representative.

Honestly, statistically = it actually is fairly meaningful and representative. I have serious = doubts if you went from 1000 to 10000 you'd see much change (and would = welcome that information if I'm = wrong).


You've also missed the = other aspect here, which I mentioned earlier: namespaced function usage = is low because the language hasn't traditionally supported it anywhere = near as well as namespaced classes. There have been multiple people = proclaiming recently that "static utility classes" are the 'wrong' = approach, that people should use namespaced functions in their code. = There are two active RFCs about function = autoloading.

This change would at best, make = those functions slower to use within the same namespace, and at worst, = more work, with a brand new inconsistency, to use within the same = namespace.

The fact that functions have = not been widely embraced as you argue would be an argument for having = this debate now, rather than later after further adding to the = complexity.

That flies in = the face of relatively common logic taken on most RFCs these days, where = potential impact on future features is a deliberate consideration, so as = *not* to negatively impact them, rather than an attempt to "get in = first" regardless of negative consequences down the = line.



The = change we're talking about is in the range of maybe 2-4%, and is 100% = solvable in userland - and has been for those 15 years, in a way that = has zero impact on developers using the language to write their own = functions, and is consistent with the way other symbol lookups (e.g. = classes) work. I'll concede you one point. A footnote is clearly not = important enough for a 2% performance benefit. Let's make it the subtext = on the header of ever php.net page, just to make sure people = know.

By this logic we shouldn't have touched = list , nor should we ever add any functionality that = can't be implemented in userspace using existing tools. E.g. = array_column 

Are you referring to the `[$a, $b] =3D $array;` syntactic sugar? You = can't implement that in userland, and it didn't introduce any BC breaks, = so I don't see how it's relevant? array_column is considered to be = pretty common functionality, and the C version is about 5x faster than = the equivalent userland implementation (comparing against the polypill = the author of array_column provided) under php8.3, and was about 6x = faster under php5.5 when it was introduced.


I'm honestly not even sure where = to begin here. If you add a namespaced function to your code, and call = it from within that namespace, it will run. That's literally by design. = If that is somehow surprising to you, I'd suggest the = aforementioned name resolution page in the php manual. It's not exactly = long, you can probably read it quicker than this = email.

You say it's by design, I say it's a = bad design and should be = fixed.

Can you give an example of = any other language where global symbols take precedence over locally = defined symbols of the same name?
= --Apple-Mail=_7C8306C7-ABA9-4B14-B325-054285BF6A73--