Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125437 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 876961A00BD for ; Thu, 5 Sep 2024 15:53:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1725551735; bh=5ehcWm8YWOaOBFbkuHMbWk7Ck2iIQs7U0NsdNapdW4I=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=XfYNyMIM+ofjEHhPt2f89UL++WViCV2wmLmxYxQPa2SLaWNY3EyX7U0ZQioOKUudU icaJAWoK5ZhrxyvEpsZc9Rlw8XhEODMPjkVXza7aUK3QZZpGvnW/n+Xe9pl3z+5Mnb fJYaRWRkzE17pKfqViJp6CYO/Lp55ihSbDTlXLoaqp1D6B98uWLMU00UXijE1Q0vif AEsTvBjtasW3e6jau5Zm66gkcRTMXkDufEwU9cUQ4y/bGdWrJvN3DE/1zwECfpaTxx SMTGclXd4b/J1eRWxfvCVE94zoG0EdmhS6hqPnzr4wDm/1/T9hjN2VRcbQiUdBcYBq 2+dSYrLfp3RfA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 11592180068 for ; Thu, 5 Sep 2024 15:55:34 +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-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) (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 ; Thu, 5 Sep 2024 15:55:33 +0000 (UTC) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-6d4f1d9951fso8606487b3.1 for ; Thu, 05 Sep 2024 08:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1725551614; x=1726156414; 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=45XQhbxZX3+/9Gy7u/9OdjlsP6fmlyxwe7hkZ6+m/s4=; b=cE4XOfV/ofpefXfWA+66F+a6q2JpBQ8IXLymuDihPA9eP4QiHpKjlUW7vup+03uKs4 l1YqTGl2arxyNrXVnFx77TTAJpLrdivNSrLyCK7+sVG8cVFQTYThS3lttpL2bVZLZQHD XE4IT+0/Id/oEWAh5QjnVG8IbEXnrYNBzqZX1GwoVLylU8seyEIcU/vVph+kEomI9s3E VS4IENjHHOwE5rC5JvOoVPrgGtyVXtRnwLCVBvang5RpciTBauMvwOfyLboLe9LOjbSf WPYiDGlgJg4a9MSmDXEbR+98cXLOaHfUKwyZS7s30Y+3r6EyJTmH/c/v+46/aSB2kTeF 17Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725551614; x=1726156414; 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=45XQhbxZX3+/9Gy7u/9OdjlsP6fmlyxwe7hkZ6+m/s4=; b=nW2vEIRhlU96bkMrEaqCRJfv9B5u3bbfltD74KL4qUJ6iNvpd53tlZN/KiTAcei+of jDVyYnaMNzvseD2hQNwZzbsmLm8Unuo8qk708USUNzqV6SbyY3PqmyZz6Wv+fMCb50W+ AyNXklKYxSDtHLz2JXRazq9DASLGW2bh5bGLW+Ogvn/FFwBJRzM1+lpX3sZIvNt1VTdU UNCWb4npjzfk5OQA1vk8GEL3mbD6Xkhgw4RjUFU49Q/VDc7wvL9KhC1UTueuHo8Y6UQ+ kPscsDxHlDVWc4mbFotKxfTuFqgg+sDboudu/2rOCd1RUtWl0itMGWEuHeFXLc2pIB+/ Br8w== X-Forwarded-Encrypted: i=1; AJvYcCU+uGuH6Xqn4V0E76coRdfvkKoH8MzOrFbkhvi1xTpe+fH9xaAnbbhrxtbsk0bu5uc0teBRgKtHz2s=@lists.php.net X-Gm-Message-State: AOJu0YwYVJAnNuE5r2HGLJQ77KyguQ/bBbuqjsf8MRLo/QBTo4pQ7utO JpPc2X9sBL7d8F6sD1TSS087mi5zi/GO1HzERDbwloW+SPXMA/pbbgRpHIxwpHfoORcwJ+4uawt 1bOQ= X-Google-Smtp-Source: AGHT+IGx6IGtqgd2lu8DG8oTz4IxK2nRBKSdBOkPEY8Hhtxp2o0R6IFeFJFq2c3Z5iIaTZaaSCX8HQ== X-Received: by 2002:a05:690c:6289:b0:6d6:b368:bff2 with SMTP id 00721157ae682-6d6b368c480mr187663597b3.18.1725551614252; Thu, 05 Sep 2024 08:53:34 -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 00721157ae682-6d2d57de3fbsm29295537b3.78.2024.09.05.08.53.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2024 08:53:33 -0700 (PDT) Message-ID: <77C2D2CC-5E1E-40D9-9FB3-A5C4A6311669@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_A7744EDF-1670-4D8F-81BE-3F1D32CCB361" 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.10\)) Subject: Re: [PHP-DEV] Local constants Date: Thu, 5 Sep 2024 11:53:32 -0400 In-Reply-To: <94510a5e-ae23-4118-ac55-2e90c911e7da@app.fastmail.com> Cc: John Bafford , internals@lists.php.net To: Rob Landers References: <27c3909f-05f4-4256-a447-10e8d8760fff@app.fastmail.com> <420bb5cb-5fca-4f2e-8c68-0ca327cd3392@app.fastmail.com> <7A98532B-7465-4FC5-B7A9-993E7D430EE1@zort.net> <94510a5e-ae23-4118-ac55-2e90c911e7da@app.fastmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.10) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_A7744EDF-1670-4D8F-81BE-3F1D32CCB361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 4, 2024, at 5:41 PM, Rob Landers wrote: >> > On Sep 4, 2024, at 16:45, Rob Landers > wrote: >> >=20 >> > I think, conceptually, this makes sense, but maybe I'm the only one = who writes >> >=20 >> > $arr =3D doSomething(); >> > $arr =3D array_map(fn($x) =3D> $x->prop, $arr); >> > $arr =3D array_filter($arr, $filterFunc); >> >=20 >> > instead of >> >=20 >> > $arr =3D array_filter(array_map(fn($x) =3D> $x->prop, = doSomething()), $filterFunc); >>=20 >> IMO, that's a failing of PHP not supporting object syntax (and = reasonable api) for non-object values. In other languages, I can write = code such as: >>=20 >> let arr =3D doSomething() >> .map { $0.prop } >> .filter(filterFunc) >>=20 >> Which is more readable than both PHP versions. >=20 > I think that sidesteps the reality we are currently in and is = orthogonal to the actual problem I perceive. To be more clear, I think = with the current APIs in PHP, having local constants would incentivize = people to write less readable code for the reasons you mentioned.=20 It could ALSO incentivize people to write their own wrappers =E2=80=94 = easily done in userland =E2=80=94 or include a package that has those = wrappers already written, and then they *would* be able to write more = easily-readable code like this: const WIDGET =3D getWidgets() ->map(fn($w) =3D>$w->prop) ->filter($filterFunc); Further, as part of the announcement of the new feature that PHP we = could write that PHP considers it a best practice to use said wrappers = rather than to write code in the less readable format you presented. And if people instead do as you fear it would provide more incentive for = PHP to add such quality-of-life improvements into core. > Maybe, but I only mention that block-scope would be more valuable than = local constants. That they work well together is also interesting. Block-scope? Please, just no.=20 As someone who also develops in Go, one of the biggest mistakes they = made in language design IMO is block-scoped variables. In my anecdotal = opinion, block-scoping is one of the more insidious foot-guns in the = language as it is all too easy to accidentally shadow a variable that = you did not intend to shadow which can result in a hard-to-track down = bug. =20 Not convinced? At least one other person has my same view of the dark = despair of block-scoping: = https://forum.golangbridge.org/t/warning-for-accidental-variable-shadowing= -with-block-scope/4715 Of all the Go code I have written, I'd say accidental variable shadowing = is in the top-three (3) reasons for bugs in my code, if not the main = reason. And if it were not for BC breaks, I would lobby hard for Go to = remove it. I know that some on the Go team lament that they ever = included it. So while block-scoping appears to be a panacea, it is really a wolf in = sheep's clothing. > This is a problem that I have run into in only a handful of times in = my entire career, across all languages, lots of times in JavaScript = files of yesteryear when we had to deal with 10k loc handrolled files. = I=E2=80=99ve seen this happen maybe 2-3 times in php (where it has been = a bug), and a couple of times in C. I don=E2=80=99t think I=E2=80=99ve = ever run into it in C#, Scala, or Python. Maybe I=E2=80=99m just lucky, = but I don=E2=80=99t feel like this is a valid reason for the feature. I have run into this problem a handful of times in the past *month* = including in other people's code, so clearly one person's experience is = not universal. > Const was added to JavaScript (according to my cobwebbed memories) to = introduce block scoping and optimizations around that. In PHP, we also = have function scope, like JavaScript, but we also have lexical scope as = well. Javascript did not have that at the time; in other words, the = following would have output "world": > > Today, it doesn't, and neither would php. The problems that const/let = set out to solve in Javascript do not apply here, IMHO. There are other languages that exists outside the web bubble of PHP and = JavaScript, and most have local constants for which "the reasons they = were added to JavaScript do not apply to PHP" =E2=80=94 a claim for = which I do not know enough of this specific history to opine =E2=80=94 = do not apply: Java/Kotlin, Swift, Go, C/C++, Zig, and Rust (while = ignoring TypeScript given its roots in JS.) Simply put the reason for local const is to declare an immutable = variable, one whose value we know cannot change. One key reason relevant = to PHP is to ensure its value is not changed by reference by a function = you are calling, but also so that you don't accidentally change it in = the same function. And here are some more reasons elaborated:=20 = https://stackoverflow.com/questions/622664/what-is-immutability-and-why-sh= ould-i-worry-about-it -Mike --Apple-Mail=_A7744EDF-1670-4D8F-81BE-3F1D32CCB361 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 4, 2024, at 5:41 PM, Rob Landers <rob@bottled.codes> = wrote:
> On Sep 4, 2024, = at 16:45, Rob Landers <rob@bottled.codes> wrote:
> 
> I think, = conceptually, this makes sense, but maybe I'm the only one who writes
> 
> $arr =3D doSomething();
> $arr =3D array_map(fn($x) =3D> $x->prop, $arr);
> $arr =3D array_filter($arr, = $filterFunc);
> 
> instead of
> 
> $arr =3D = array_filter(array_map(fn($x) =3D> $x->prop, doSomething()), = $filterFunc);

IMO, that's a failing of PHP not = supporting object syntax (and reasonable api) for non-object values. In = other languages, I can write code such as:

let arr =3D = doSomething()
    = .map { $0.prop }
    = .filter(filterFunc)

Which is more readable than both PHP = versions.

I = think that sidesteps the reality we are currently in and is orthogonal = to the actual problem I perceive. To be more clear, I think with the = current APIs in PHP, having local constants would incentivize people to = write less readable code for the reasons you mentioned. =

It could ALSO = incentivize people to write their own wrappers =E2=80=94 easily done in = userland =E2=80=94 or include a package that has those wrappers already = written, and then they *would* be able to write more easily-readable = code like this:

const WIDGET =3D getWidgets()
   ->map(fn($w) =3D>$w->prop)
   ->filter($filterFunc);
Further, as part of the announcement = of the new feature that PHP we could write that PHP considers it a best = practice to use said wrappers rather than to write code in the less = readable format you presented.

And if people instead do as you fear it = would provide more incentive for PHP to add such quality-of-life = improvements into core.

Maybe, but I only mention that block-scope would be = more valuable than local constants. That they work well together is also = interesting.

Block-scope?  Please, just = no. 

As someone who also = develops in Go, one of the biggest mistakes they made in language design = IMO is block-scoped variables. In my anecdotal opinion, block-scoping is = one of the more insidious foot-guns in the language as it is all too = easy to accidentally shadow a variable that you did not intend to shadow = which can result in a hard-to-track down bug.  

Not convinced? At least one other person has my = same view of the dark despair of block-scoping:


Of all the Go code I have written, I'd say = accidental variable shadowing is in the top-three (3) reasons for bugs = in my code, if not the main reason. And if it were not for BC breaks, I = would lobby hard for Go to remove it. I know that some on the Go team = lament that they ever included it.

So = while block-scoping appears to be a panacea, it is really a wolf in = sheep's clothing.

This is a problem that I have run = into in only a handful of times in my entire career, across all = languages, lots of times in JavaScript files of yesteryear when we had = to deal with 10k loc handrolled files. I=E2=80=99ve seen this happen = maybe 2-3 times in php (where it has been a bug), and a couple of times = in C. I don=E2=80=99t think I=E2=80=99ve ever run into it in C#, Scala, = or Python. Maybe I=E2=80=99m just lucky, but I don=E2=80=99t feel like = this is a valid reason for the feature.

I have run = into this problem a handful of times in the past *month* including in = other people's code, so clearly one person's experience is not = universal.

Const was added to JavaScript = (according to my cobwebbed memories) to introduce block scoping and = optimizations around that. In PHP, we also have function scope, like = JavaScript, but we also have lexical scope as well. Javascript did not = have that at the time; in other words, the following would have output = "world":
<snip>
Today, = it doesn't, and neither would php. The problems that const/let set out = to solve in Javascript do not apply here, = IMHO.

There are other = languages that exists outside the web bubble of PHP and JavaScript, and = most have local constants for which "the reasons they were added to = JavaScript do not apply to PHP" =E2=80=94 a claim for which I do not = know enough of this specific history to opine =E2=80=94 do not apply: =  Java/Kotlin, Swift, Go, C/C++, Zig, and Rust (while ignoring = TypeScript given its roots in JS.)

Simply put the reason for local const is to = declare an immutable variable, one whose value we know cannot change. = One key reason relevant to PHP is to ensure its value is not changed by = reference by a function you are calling, but also so that you don't = accidentally change it in the same function. And here are some more = reasons elaborated: 


-Mike

= --Apple-Mail=_A7744EDF-1670-4D8F-81BE-3F1D32CCB361--