In a similar vein to "use strict" we could create a new directive that disallows JS features like var, prototype, == (in favor of ===). Modules with this new directive at the top of the file would be executed under these new rules. You'd be able to create new (maybe lighter weight) JS interpreters that only target this subset.
I don’t think anyone uses var anymore. Linters and prettier are doing a good job keeping codebase consistent.
Operator == has a valid use case (null or undefined check) but rarely allowed as well.
But I wouldn’t mind to have language without legacy.
<script>
var x = 1;
if(x < 5) {
// now y is global (window.y can be accessed everywhere)
// using const y = x * 2 would be inaccessible outside the if block
var y = x * 2;
console.log('double x is: " + y);
}
</script>
Besides that, var is "pulled" upwards, as if it was the first line in the function. That may have side effects.
Where I work now basically does quarterly deployments. We service enterprises that generally outsource their development work. So we deploy pretty regularly to a staging environment and deliver documentation weeks/months before we actually deploy it. The exception to that rule is for hotfixes, which is also extremely rare. Like 2-5 times per year.
Something (unrelated) that surprised me here is that the author has two decades of posts on this blog, leading back to their first post about a new version of C# (https://codeblog.jonskeet.uk/2005/09/)
Personally as a younger software guy I had no idea that C# had type inference back in 2005- an interesting perspective shift!
I'd be curious to read about what percentage of active PHP devs use the recent features. The last time I worked in a PHP codebase (2020?) was half PHP 5 (bad) and half PHP 7 (much nicer). Curious if there's any real info out there on this
PHP 5 is as close to phased out as it gets at this point. No doubt it's still in a lot of legacy enterprise codebases (lots of breaking changes going from 5 to 7 or 8), but outside of that no one is using it.
Yeah, and I just finished porting an enormous amount of production code from PHP 5 to 7.x before fully moving it to 8. There are so many breaking changes in each major version, when you have a lot of live projects and clients don't have the budget to pay you to upgrade them, they can lay stagnant for years until way past EOL. It would have been nice to know, for instance, that future versions of PHP would throw warnings about undeclared variables or unaccessible named properties of "arrays" - which could previously be relied upon to be false-ish. That's a major pain point in code bases that treated arrays as simply dynamic objects that could be checked or defined at will. Lots of isset() and !empty() and other BS. Fine, but it takes time to sit down and check it all. I really preferred it when it let you just screw up or try to access a null property or define a variable inside a block and access it later without throwing any errors at all. Nothing about its actual functionality has changed in that regard; it's just errors you have to suppress or be more verbose to get around. In PHP 8 you can still do this:
PHP still knows what $previouslyUndefined is or isn't at the second if statement, but it'll throw an error now in the first statement if you hadn't declared it outside the block. Why? Who cares? Scope in PHP is still understood to be inline, not in block; there is no equivalent to let vs var in JS. Stop telling me where I can check a variable if you're not enforcing various kinds of scope.
Your $previouslyUndefined thing as something that's changed, as far as I know, isn't true? Unless I've missed some very recent change.
If $a is true, that snippet will just execute with no errors. If $a is false you'll get a warning trying to check $previouslyUndefined in the second if. That behavior's been the same for a very long time. The blocks don't matter for scope but the fact that you never executed the line that would have defined the variable does.
Similarly, warnings on accessing array keys that don't exist, that's been a thing forever too. Pretty sure both go back with the same behavior to PHP 4, and probably earlier.
Yes, and this is incredibly annoying. Many packages add them as a dependency, and then you get subtle bugs because of it. Or worse, they add a dependency for the polyfill that is related to an extension and suffer performance issues when the extensions are not installed; yet no warning is output.
reply