> 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 >> > <mailto:rob@bottled.codes>> wrote: >> > >> > I think, conceptually, this makes sense, but maybe I'm the only one who >> > writes >> > >> > $arr = doSomething(); >> > $arr = array_map(fn($x) => $x->prop, $arr); >> > $arr = array_filter($arr, $filterFunc); >> > >> > instead of >> > >> > $arr = array_filter(array_map(fn($x) => $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 = 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 — easily done in userland — 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 = getWidgets() ->map(fn($w) =>$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: 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’ve seen this > happen maybe 2-3 times in php (where it has been a bug), and a couple of > times in C. I don’t think I’ve ever run into it in C#, Scala, or Python. > Maybe I’m just lucky, but I don’t 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" — a claim for which I do not know enough of this specific history to opine — 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: https://stackoverflow.com/questions/622664/what-is-immutability-and-why-should-i-worry-about-it -Mike
