I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.
#[SkipDiscovery(static function (Container $container): bool {
return ! $container->get(Application::class) instanceof ConsoleApplication;
})]
final class BlogPostEventHandlers
{ /* … */ }
Given that the cat effectively is out of the bag, does the example on the release page (sneak preview) make more sense to you: https://www.php.net/releases/8.5/en.php#closures-in-const-ex...?
> As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#"
Yes, unfortunately the off-the-shelf software of the Wiki uses a custom-built highlighter instead of the `highlight_string()` function that is bundled with PHP: https://www.php.net/manual/en/function.highlight-string.php
Clout.
I have no clue what the future brings for PHP, but PHP 8 is definitely a good start, and we should put PHP 5 to rest.
PHP 10 might not be that different from PHP 8 for all I know.
We do not know if there will be "constant change". Out of curiosity, what programming language do you use that you also love?
FWIW, if by "constant change" you mean improvements or bug fixes, then I do not see why we should not have those. I do not even mind breaking backwards compatibility if the reasons for breaking justifies it, but it has to be a really good reason.
Python's success is explained by it being the language of choice for AI.
I think the reason is that it is easy to learn enough to get things done, but it is very flexible, very readable, and once the ecosystem started gaining momentum (which it clearly had by the time of the XKCD cartoon) that became an advantage too.
The only one that's caused me any significant stress is the deprecation of the old `mysql` DB interface; I had to refactor a whole bunch of code for that, since I'm maintaining a codebase that's been in continuous use & development since 2001.
The additions to PHP since 5 add more things you can do, but they don't really change the simple things you can do to first learn PHP. You can still just create a .php file and start interspersing HTML and <?php script tags with basic operations.
Java and C# are a couple other popular languages where the same is also true.
That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.
Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.
A person that invests time into their language knowledge will not have issues handling new syntax because they spend as much time as necessary to get familiar with the new syntax
So the criteria is being a 9-5 who doesn't particularly care about coding and doesn't invest time into their language knowledge
If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.
“Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”
And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.
And I would double down on my bet regarding ISO C related questions, as I have met a few folks that contrary to myself as language nerd, hardly know what is written there or have even opened the PDF drafts at least once in their life.
But, if you want an answer to your question:
You can learn to avoid undefined behavior in about 30 seconds.
If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.
> You can learn to avoid undefined behavior in about 30 seconds.
Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.
Before when?
Microsoft(R) MS-DOS(R) Version 6.22
(C)Copyright Microsoft Corp 1981-1994.
C:\TMP>type foo.c
void main() {
long q = 0;
q = 0/q;
}
C:\TMP>cl /Od foo.c
Microsoft (R) Optimizing Compiler Version 5.10
Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved.
[...]
C:\TMP>foo
run-time error R6003
- integer divide by 0
C:\TMP>type bar.c
void main() {
long far *p = 0;
long q = 0;
*p = 0;
q = 0/q;
}
C:\TMP>cl /Od bar.c
[...]
C:\TMP>barBut PHP 5 was released 21 years ago and is unsupported. Companies using it are putting their customers at risk.
non of the "modern" things are particularly taxing to teach someone with more than two braincells. If they don't understand them then they haven't kept up with ANY programming trends in the past decade and are best placed infront of the TV with an iPad than left to mess with the possible critical infrastructure of a business.
TLDR: The PHP compiler isn't really suited for the job, it would introduce a lot of complexity to an already complex codebase and the memory/performance hit would be substantial.
Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.
Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.
> Adding generics to PHP would make CS fundamentalists somewhat happy
PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.
For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.
PHP chose to check types at runtime. To check that a value is really an array<int> the runtime could have to loop through the entire array. All the types PHP currently implements are simple and cheap to check. For more elaborate cases you need an offline checker like PHPstan and comment-based type annotations. (PHPstan catches 99% of issues before the runtime gets to it so for my own code I'd prefer the Python approach with its cleaner syntax.)
The runtime checking seems the key difference, not so much the historical strength of the type system. Python's language implementation does very little typechecking itself and PHP's third-party offline typecheckers are respectably advanced.
This could be the way PHP could go, they just need the lexer to handle types, and not do any runtime checking at all.
But i guess that goes against what the php devs want, but it sounds so wasteful, to typecheck the same code time after time even if it passed some sort of initial "compile time step".
This subtle difference has huge implications. You could in theory have an "compile step" in. Python, but in PHP you really cant as the program is never "running".
Python built syntax for types / generics etc. Its actually a quite capable typesystem (im not a python developer, but use python on some occasions). Python then has tools for static typechecking that can be run outside execution.
This means that if python would do actual static typechecking on runtime it would be nothing more than wasted cpu cycles.
Thats why python opted for the syntax only, as its basically zero cost. In php land the typechecking is done on EVERY execution, even if the code was unused. (a void functions that has an int param, but gets passed an string, that just discards the parameter). Even worse, a type error thats not executed wont be caught by every execution.
In short PHP typesystem is just runtime checks for primitives / classes and wont catch errors where not executed. Its like the worst of both worlds.
What do you mean by this? The types of variables in PHP >8 are not in comments. Or did I misunderstand something?
Why is it bad?
In particular, why is it worse than not being able to declare a typed array in your current scope? (I understand the basic argument in favor of typed arrays, but I also understand why PHP would choose not to go that route; I'm not sure I see how it's worse to not be able to return one from a function, given that they don't exist elsewhere.)
A even more simpler example is An array of some sort of Item. I cant return array(Item), but i only can return an array.
What is not working?
But that is no different than if you created the array in that scope.
So, again: Why is it "really bad" that you can't return a typed array from a function? What is worse about that than not being able to create a typed array in the current scope?
Also: What, exactly, about that is "not working"? As I said above, I understand the basic arguments about typed arrays; they're conceptually equivalent to weak/dynamic types. And there is value in having strong and static types. But it's hardly a showstopper not to, and PHP works just fine even if you don't use any. It just...makes it easier for us, as programmers, to make mistakes.
So to say it's "not working" simply because it's possible to add elements to the array that don't match the types you want seems like an exaggeration.
Yes array is the evil collection type of everything, but that's how it's meant to work. Array is the quick and dirty 'throw everything in there' thing. PHP has classes and they're very full featured and offer lots of type safety - use those.
LOL, no its not. PHP has an weak type system, while python is strong. Both are dynamic.
$sum = 10 + "50"; // 60 in PHP
sum = 10 + "50" // TypeError in pythonAlso, you can just flip on strict typing in PHP, and you should know that.
Really, that's probably enough for a lot of cases, because PHP doesn't have operator overloading. Yes, you can add '10' + 10 and get 20, but not if either of those go into any function. If you have a function that needs to do string stuff, you take string stuff in, and you don't have to worry about string operations or coercing ints or anything.