On Sep 5, 2024 at 5:46 PM, <Rowan Tommins [IMSoP]> wrote: > Block-scoping doesn't have to allow shadowing of names,
How exactly would that work? Are you suggesting to restrict the use of variable names to one per function but still allow for block scoping? Or if not, how would an inner block variable $x not shadow an outer variable $x? Shadowing is not a feature that is added, it is the result of block scoping, AFAIK. > and it certainly doesn't have to be achieved by that incredibly hard to spot > syntax. In most languages I've seen, it's indicated by either a keyword such > as "let", "var", or "my"; or by indicating the type of the variable you're > declaring. That declaration syntax is not what makes it problematic, it is the number of lines between the two declarations. I would not be so against it if most people kept their functions to 25 lines or less, but what have I have seen to think 200 to 500 line functions are the norm in legacy code I've had to work on. But then if most people kept their functions small there would be far less "need" for block scoping. (Actually — to channel Rob — block scoping could encourage people to wrote longer functions which would definitely be a negative outcome.) > For one thing, it would make me much more likely to accept the repeated > requests for closures which capture parent scope by default, because it would > give a clear opt-out to replace the current clear opt-in of the use() clause. Scoping within a closure differs from in-line blocks having their own scope. For one, a closure is separated by a parameter stack whereas a block shares the stack with its function. Closures can be assigned to variables and objects properties and also passed to functions, blocks cannot. Closures have their own return values, blocks have no return statements thus are coupled to the function's scope. And finally and most importantly, the point of a closure is to delay or delegate execution whereas blocks execute inline with the function where they are located. For all these reasons local scope makes sense in closures whereas IMO scope in blocks does not. > It's something I'd really like to see in PHP. Be careful what you wish for. But don't say I did not warn you if it comes to pass. > I've never found myself wishing for local constants, but never really used a > language with them, so maybe I'd find them valuable if they were added. Ignorance is bliss. And I mean that literally, not pejoratively. > For completeness, I'll mention that *typed* local variables are another > related concept, which has also come up in the past. You'll get no argument from me on type local vars. > The big challenge in all of them is that these are big fundamental language > changes, which require an expert knowledge of how the language works under > the hood Really? I believe what the OP was asking for — or at least it is what I would be interested in — are immutable variables that we could conveniently declare with `const`. I could be wrong but it seems the only thing it would require is the compiler to throw an error when asked to generate a variable assignment opcode to any variable declared as a const. The above assumes piggybacking on variables with `$` syntax vs. no-`$` syntax, so maybe using `const` would not be the best keyword. We could use `var` but that doesn't indicate immutability. Or it may possible that implementing as `const` w/o `$` syntax would not be hard given that global const names are already recognized by the parser. And they could internally be kept on the same stack as variables. > Let's not get too deep into discussing the colour of the bikeshed before > we've worked out if there's space to build one. It is ironic you say we should make sure it's possible before we discuss if we want it. I know I have heard the opposite many times on this list — make sure we even want it before we worry about how to implement — although I cannot say for sure that it was ever you that said that. Whatever the case, of the features that have been implemented in recent years I find it hard to believe adding local constants would be nearly as hard as some of those features. Certainly easier than aviz. -Mike
