The language isn’t perfect but I love working with it, these 8.1 and 8.2 improvements have really made it sweet.
My biggest gripe at the moment is the (very old) behavior of e.g. preg_match() and sort(). You’ve got a small handful of these common functions that operate on their input by reference/in place which is gross. A new version of these would be welcome.
PHP just happens to be good at getting stuff done fast, so it's found all over the place, and thus has a lot of eyeballs on it. The negativity is a byproduct of it's usefulness and staying power - the price of popularity, if you will.
I love PHP, especially with the new event loop based modules that let you do things asynchronously, much like Node or Go.
If you know how to use it well, PHP is awesome, and it's getting better with each release.
PHP opened the door to cheap web dynamic web hosting and in turn you had self-hosted applications like Wordpress. It was a few years later that languages like Java and C# became really attractive for back end work, you also had Ruby, Node, etc.
I wrote a lot of PHP in the early 2000s because that is were the work was, that’s what you could write open source code that people would use in, and it was really straightforward to build apps (like a social network for a secret society) without an ‘ops’ team watching your every move.
I've only done PHP for small personal projects and some wordpress hacking, and that was years - so my experience is limited. But it seems to me that one of the great and tragic things to PHP is the low barrier to entry. As you put it: "first open source language in which just anybody could write server-side web applications without terrible management problems for the sysadmin".
This made it extremely easy for anyone in the early 2000s who signed up for a web hosting account on godaddy/hostmonster/hostgater/etc... to fire up a text editor of their choice and start slinging code and FTP'ing up to a server. Didn't have to worry about installing, configuring, all the dependencies, build tools, etc... just edit, upload, refresh -- lather, rinse, repeat until it works. Lowered the barrier to entry, and got a lot of people into the field. Really powerful stuff.
It also made sloppy, hacked-together, copy-pasta code very prevalent. In my limited perspective, I suspect that this prevalence of sloppy spaghetti-code has contributed to PHP's bad reputation. It's not that you can't do good code (totally can!), but a PHP environment can be forgiving of some pretty bad practices.
Deploying to the cgi-bin directory was more convoluted and error prone for end users. Even when you did it right all of your URLs had an "ugly" cgi-bin component.
The easy deployment and cheap shared hosting with their managed MySQL instances really helped boost PHP's usage.
I don't recall the sequence of events that way. That is, there was regular cgi, then mod_php with problems similar to mod_perl...then later fastcgi options existed for both.
I don't like arguments like these because they're a tu quoque without even bothering to point out flaws in a different thing. It implicitly states that progress is impossible, that all languages will always be as bad, and nothing can ever improve because once a technology is widely-used, design flaws will magically appear. If you really believe that, write your next website backend in FORTRAN IV.
It was lazy argumentation when it was people saying Linux was just as buggy as Windows Me and it's lazy argumentation now.
> Progress is impossible
Huh? My very last sentence implies quite the opposite.
PHP has made huge strides in progress over the last decade.
Php is in a very similar situation, the difference is you can't escape javascript so we all to some extent keep up with its developments. People who leave php left it at a certain point and their understanding of its issues is frozen there. It's very predictable and boring honestly.
In fact php with composer and tooling is really good these days. Most people I've met (in person) who hate on php can't say why. They tend to equate php with wordpress.
I've picked up their projects and see many problems but I don't go blame the language they chose.
Yes it's a userland workaround and not a fix for the language, but it's thinking about these issues and a PHP extension (offering better performance) is being talked about.
The no-brainers to me are the missing array_some()/array_any() array_every()/array_all() and an array_search() that takes a predicate and iterable. I do these now in userland but an optimized native version would be nice.
What does that lib do that PHP doesn't?
Does it deterministically pass ALL tests in its own test suite yet? 100% of the time? This was the state just a few years ago, where a lot of tests were simply disabled because they were "flagging". <insert eyeroll emoji> (I'm not even going to touch the Boolean chart showing the different behaviors of single, double, and triple-equals on results. I know a lot of that has been fixed, at least by "convention".)
Nondeterminism is literally the worst trait of a computer language, because it leads to the worst kinds of bugs- the ones that are NOT a result of your lack of understanding of how the code is supposed to work at the PHP level. I've literally burned months away in my career in tracking down bugs like this (in Ruby and other languages), which ended up being framework or language bugs. There comes a point when you say "never again". Unfortunately, it comes too late in most people's careers to realize they've made a mistake, and switching to another language/community becomes too expensive/risky a proposition for them. (In my case I've been fortunate in that I was able to switch from .NET, to Ruby, to Elixir... each one of these was a difficult transition, both intellectually and socially (I really miss the Ruby community!), but in the end, completely justified in my case.)
Do you mean how you can have an optional out parameter to get more detail than what the return parameter gives for which group matched?
Personally i dont see anything wrong with that, but to each their own.
>sleep(int $seconds)
>returns zero on success.
>If the call was interrupted by a signal, sleep() returns a non-zero value. On Windows, this value will always be 192. On other platforms, the return value will be the number of seconds left to sleep.
I've used it for 2 years 2 years ago and I'm not at all interested in starting a project with it again
PHP is nothing if not amazingly well documented. This is more than I can say for a lot of languages I have worked in cough Ruby cough. I work pretty heavily in Go these days and even it’s docs leave me wanting in comparison sometimes.
The projects I start today got the php replaced by typescript
As for the second part, I understand why system calls are interruptible, particularly before the implementation of many syscall-level asynchronous operations. However, too many languages require too much boilerplate in the much, much more common case where the developer wants the appearance of an uninterruptable system call in a multi-threaded and/or multi-actor program.
I've written plenty of interruption-safe sleep and I/O code in C. It's disappointing that same C boilerplate needs to be used in PHP, Java, etc. If you want to expose the interruptiblity of a C sleep(), call it interruptible_sleep(), and make sleep() a wrapper that contains the boilerplate you want 99% of the time in C. I dare say 90+% of programmers don't properly deal with interrupted sleep system calls, and exposing the interruptions should be opt-in.
In retrospect, at the syscall level, the C library interface to interruptible syscalls should take a function pointer to an interruption handler that returns a boolean as to whether the syscall should be transparently resumed. Passing a null handler should result in the syscall appearing uninterruptable to the calling code. Most programmers are blissfully ignorant of interrupted syscalls and are perplexed by seemingly random resultant bugs. The default interface to these calls should protect the programmer.
// sleep(int sec) should look more like:
void sleep(int sec) {
sleep_interruptible(null, sec);
}
void sleep_interruptible(bool (*handler)(int), int sec) {
struct timespec ts = {sec, 0};
int prev_errno = errno;
errno = EOK;
while (nanosleep(&ts, &ts) != 0 && errno == EINTR) {
if (handler != null && ! handler(errno))
break;
}
errno = prev_errno;
}Non-java devs think of java as Java 6 when in reality it has pretty significantly evolved in the last decade. I dare say that it's one of the most rapidly evolving mainstream languages on the market at this point.
We’re always looking btw.
How we train our dev's is to use those courses and to have our current PHP/Sugar dev mentor them on the differences.
Or even which of those companies even hire PHP devs anymore?
Great! Keep using it! Ignore us. We (detractors) also had to use it and have since learned (hopefully several) other languages that (not looking at you JS) we like much better... :)
If you've long moved on and are no longer using PHP, why do you still consider yourself a "detractor"?
I still occasionally work with PHP for WordPress and it is still mostly not great. The mess of abstractions, the JS-like library installation system, the lack of any kind of concurrency, the mess with errors vs exceptions.
It just isn’t a language that makes me happy. Then again, I dread opening a .php file so maybe it’s a preconceived notion.
If it's recognition for learning <insert-language>, how do I provide it to you?
Have you consider that people who learn other programming languages are not doing so in order to claim that they're better than PHP programmers, but for their own intrinsic reasons?
It's such a weird, fragile ego situation. Does everyone else have to pretend that PHP is the only language that exists in order to placate your sense of inferiority?
Major update, awesome. /s
As someone who manages a network of 250+ WordPress websites - these PHP updates are killing me! As soon as I'm done helping clients upgrade/fix their incompatible themes/plugins and custom code, a new version is out! Even with great tools, the process for about 10% of my network is a nightmare.
While I appreciate the work, it's not very satisfying and for many clients very frustrating to pay for something they know nothing about, just to "keep the lights on".
The plugin/theme developers usually develop with older versions of PHP in mind, lot's of plugins still work even with 5.x versions...
For my WP sites I just stick with "two major versions behind" workflow and I don't encounter many problems.
Am I doing it wrong?
Moving from 7.4 -> 8.2 will be just as much refactoring as moving from 7.4->8.0->8.1->8.2. Security support is in general three years [0] so everything 7.X is now unsupported. Considering the security cadence you can skip one version, but if you skip two you'll probably be out of security support before you migrate to a new version. My philosophy is if you're going to need to do the work to upgrade anyway, you might as well do smaller chunks more frequently and be able to take advantage of the language goodies that come out earlier.
The amount of the language that gets deprecated every year is PHP's fundamental flaw, at least in the last five years.
GP's problem seems to be that they have to support WordPress plugins and themes that they either can't or don't want to patch by themselves. This is a different situation from people who build & maintain in-house apps. In that case, always using the previous Ubuntu LTS is a perfectly viable solution. Stay 2-3 years behind the edge, giving enough time for the plugins and themes to get updated, while still receiving security patches and comfortably within the recommended range for WordPress Core.
Eventually you have to upgrade. Do you want to go from 5.6 to 8.2 and possibly have to start over? Or do you want to go version by version, paying smaller amounts more frequently to stay current?
Also: WordPress + Themes + Plugins works best when you don't delay maintenance/upgrades. Everything needs to work in concert. You might be able to freeze your theme in time, but your plugins and the WP core will march on.
A lot of cPanel or similar hosts are also retiring old versions as they hit EOL [1][2][3][4][5] (those all support 7.4 still but most have indicated that will be dropped next year as well). This has made hosting transfers more and more difficult if you don't want to go through the process of upgrading.
The process of upgrading Wordpress sites isn't so bad (generally there's no work, honestly). But not all CMSs are that simple and it can get more laborious when you want to upgrade a Laravel or Symfony site, especially if you've skipped a few versions.
Of course, at the end of the day, it's up to the client to provide budget for these things and if they don't/can't, you just have to push back on their other requests until they do.
1: https://in.godaddy.com/help/retiring-old-php-versions-41164 2: https://www.bluehost.com/hosting/help/php-version-selection-... 3: https://help.dreamhost.com/hc/en-us/articles/215082337-What-... 4: https://wpengine.com/support/php-guide/ 5: https://getflywheel.com/wordpress-support/php-on-flywheel/#p...
7.4 just ended its security support so you might argue that you should be at least on 8.0 just in case a bug is found and not backported.
Truth is: it's not likely.
But in any case theres no need whatsoever to use the latest version and even less when you are using WordPress which is notoriously bad at keeping up with PHP releases.
PHP 8 is in "beta support" currently, but that's just Core. A lot of plugin developers are lightyears behind it seems:
https://make.wordpress.org/core/handbook/references/php-comp...
[0]https://www.cloudways.com/blog/wordpress-performance-on-php-...
https://www.php.net/supported-versions.php
I know the web needs constant maintenance, but I wish it wasn't so much. PHP has been pretty good about not breaking changes, but I've noticed a few..
PHP is my goto. Its pretty great. It enabled a startup I was part of to get off the ground.
I think official LTS for PHP would still help, if only to drive a few of the larger developers to target those versions to ensure maximum ease of deployment and maintenance.
Shared webhosters (speaking for Germany) have started to disable support for PHP 7.x as there are no security patches anymore.
That made it necessary to upgrade lots of WordPress pages, especially older ones had some quirks in themes that broke with PHP 8.
I've updated around 25 sites for an old friend (she's more into the design/content part, not the dev part) and made good money with that. "Stupid" work nevertheless, would've preferred to do something better than run a PHP 8 linter and see where it breaks...
It's unreasonable to expect standard hosting providers to cater to those kinds of needs IMO.
Exactly. It's work for our engineers but not something to get excited about. Plus you need to explain to the client why they're paying $1000 for something called "PHP" which they have no concept of.
So there's some argument to be made to be in the 8.x series. It's probably not something you should be losing sleep over just yet, but at least have it on your roadmap to address in the coming months.
We upgrade our clients in waves, so sites in dev get the latest PHP, which lets up contribute to upstream PHP projects to fix issues, and by the time it's merged upstream, we can update our older clients without any worries.
Also not a PHP problem but a WordPress problem. It's not a healthy eco-system.
Ding ding ding! This guys WordPresses. Even outside my network which is in decent shape, I have clients scrambling because they've ignored PHP updates for 2+ years. Sometimes burying your head in the sand is not the best strategy.
I'd argue that's true for all of PHP. Sure it got better, but compared to other langugaes it is still a mess.
Wordpress has a lot to answer for here, but given the archaic and frankly idiotic way they operate they'll do nothing of the sort.
PHP is very backwards friendly and with a strong and stable ecosystem built around composer theres no excuses for majorly used (and often very profitable) wordpress plugins lagging so far behind.
I hope you can give some factual arguments why it's still a mess.
That said there are languages where very little backward incompatible changes are made. Java comes to mind.
Also: putting each client in a sandbox (VM, VPS, etc) can help you to keep some clients on the old versions, and/or do PHP interpreter migrations on your own timeline.
I do and appreciate the job security but I respect my clients (small biz owners) and it's just not satisfying and for the 10% that have issues, costly.
Java used to be like that, but the migration to the module system has been very rocky for me personally when revisiting older projects.
I even host a few installs on the latest 7.x version.
I don't understand where this update hysteria comes from. PHP 8.1 security support ends in Nov 2024.
How do you deal with Nginx/Apache updates given they release more frequently than PHP?
You can always host at a managed hosting provider who will take care of this for you.
I don't. We just finished upgrades from 7.4 to 8.0. PHP 8 was release November 26, 2020 - two years ago!
> How do you deal with Nginx/Apache updates given they release more frequently than PHP?
My managed host deals with that.
> You can always host at a managed hosting provider who will take care of this for you.
I have a "managed" host and none of them will make your code compatible. It requires a software engineer and lots of unglamorous work.
This.
The PHP developers are trying to turn PHP into a decent, fairly modern language. This has involved quite a lot of breaking changes in the last few years, and upgrading website code just so it works with the latest version (i.e. no actual improvements) isn't appealing work.
Can't speak for Nginx, but Apache updates very rarely screw with syntax, and those are always major releases. And for Apache, "syntax" just means config files.
PHP screws with syntax frequently, and often on point releases. And PHP is a programming language; syntax is the whole point of PHP.
Python 2 -> 3 change really was painful for Python community, but PHP does these almost fundamental breaking changes so often, that maybe people just get used to it? I haven't really followed Python past version 2, but I think they are less likely to ever do such amount of breaking changes.
There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc. Someone must be pulling a lot of hairs because of this.
Edit: Those dogpiling there, I rest my case with josefresco's comment:
https://news.ycombinator.com/item?id=33907628
It's painful. Dropping dynamic properties? That will be a lot of fun. WordPress is probably biggest segment for PHP usage.
PHP also cares a great deal about backwards compatibility. There are long deprecation phases before anything gets removed.
The RFC system also helps a lot in ensuring that changes to the language are well thought out to and discussed beforehand. The is not much change just for change's sake. Churn is kept to a minimal while still allowing the language to evolve.
> There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc. Someone must be pulling a lot of hairs because of this.
PHP upgrades are also good money for agencies. Got to earn that bread.
And to let out a dirty secret, for really hopeless projects there is the option to keep them on life-support by running them inside a docker container with an older PHP version. (Horrible but if that's what the customer wants, it's their risk.)
PHP 7 made a few big and necessary changes but they generally did not affect well-written code much. Python 3 broke a lot of things without good justifications, and without a way to make your code compatible with Python 2 at the same time.
There is benefit if you have the project under test and can run the build with different php versions thought. Best in parallel so you have current, next and future. It perhaps becomes the norm since the yearly release cycle but always was a requirement when supporting different php versions.
PHP has gone through a few changes.
PHP 3->4 was a moderately big change under the hood, and introduced a lot of new things, but most 3 'worked' under 4 (but was... awkward).
PHP 4->5 - a few 'big' things changed - XML processing changed - I had to use some shims to get some projects upgraded.
PHP 5->7 - my recollection, and that of most colleagues, is that this was pretty painless for most projects. I can't recall too many major breaking changes, but it was mostly just getting a doubling of speed without any substantive changes.
The PHP community has a couple decades of 'major version changes' to look at to learn from. I still can't say I agree with 100% of the decisions, but it's still progressing nicely.
More than a LTS release I'd prefer more PHP 8 releases than the five in 7.x, e.g. more until 8.8 or 8.9.
They replaced the MySQL plugin in version 7. All MySQL code was broken. I don't know, but I'd guess that most PHP sites were using MySQL as their database (the 'M' in 'LAMP' stands for MySQL).
Then I read a little closer, and realized I pretty much just had to add an "i" onto all the underlying mysql functions ("mysql_" to "mysqli_"), at least for the ones I was using commonly.
I'm still in the process of migrating that project, now on 7.4, to a modern Symfony framework, but I tested it out in 8.1 the other day, and it needed...1 change to work apparently perfectly.
I'm still going to need to do more thorough testing before I put production on 8.x, but with 7.x now unsupported, that has become a priority.
Not quite. Code that *wasn't* using either of the two modern APIs for MySQL was "broken".
They removed the oldest, jankiest of the three APIs for connecting to MySQL in php7.
MySQLi (literally, "MySQL Improved" extension) was introduced with PHP 5.0, in 2004.
PDO was introduced with PHP 5.1 in 2005.
The documentation started showing "soft deprecation" notices on mysql_* functions in 2012. It was already common practice to advise people to upgrade to either mysqli or PDO.
The old mysql extension was deprecated as of php5.5, in 2013.
The final shipped version with the mysql extension was 5.6, which was supported until 2018 - half a decade after the deprecation was added.
Even as someone who supported it. Perhaps there was internal built up resentment.
Whatever it was it showed in their communication.
Very occasionally I have to communicate on a topic I think could see backlash based on internal views. I make an effort to communicate it as neurally as possible.
My org currently prefers a saccharin approach when there is controversy I can't stand that, but I prefer it to over the like it or lump it bristling with rage approach Python took.
> There must be a lot of unmaintained PHP codebases that will break if PHP is updated by hosting provider etc.
> Someone must be pulling a lot of hairs because of this.
I have a private (non-internet) web-app that's still on PHP6.5; I like the new PHP features, but upgrading private code to conform to PHP 7 and 8 looks a lot like make-work. I wish it shipped with good upgrade tools.
[Edit] @darkwater (below) is correct; I meant PHP 5.6. PHP6 was some kind of abortion - I can't remember the story.
I'm doing this quite often as I maintain some code-bases that have backward compat down to PHP 5.3 as the baseline. So if you're looking for forward compatibility of your PHP 5.6 codebase to 7.x and 8.x (incl. 8.2), its not so much of work.
If you need an upgrade tool, have different PHP versions at hand and load each file on the CLI and PHP will show you the deprecation warnings. It then depends a bit on the code (each()/next()/reset() family undergone some changes if not removals in 8? so you have to replace with some different syntax) but most of the rest is only deprecation warnings that can be overcome with #attributes "annotations" that are just comments prior php 8.
tooling could be better especially if you're running from low versions, thought. but using php on the cli directly brings you quite far and on speed already for most things in my personal experience. git, find and xargs are your friends.
IIRC, the initial development was in the mid 2000s but it was abandoned several years later because they couldn't get Unicode support working correctly. By the time it was abandoned there was already a lot of material referencing it like books and conference talks. So when the PHP team decided to do a new major version most of the planned PHP 6 features were already added to 5.3 and 5.4 so they thought it best to just skip 6 to avoid confusion.
Is that a joke? PHP 6 doesn't exist...
PHP didn't learn from Python 3 BC fiasco, its governance makes such changes very difficult to be made.
I know this is contradictory to what some people love about PHP, but having a directory where everything is isolated and I just run npm start or my go binary or whatever is much easier to reason about for me, rather than also have to think about Apache's end.
That won't really solve having config files at different places though.
There is however a significant overhead to Docker. Building images takes time (and you will need to build your own, if you rely on any kind of PHP extension such as mbstring, etc) and just wrapping your head around everything is harder than people make it out to be.
That being said, I used to have my own set of bash scripts to setup local virtual hosts, databases, etc, and various strategies to keep configuration contained to single projects, but things always leaked out of the boxes I tried to put it in and in the end all those strategies failed.
So, my current estimate is that Docker doesn't save me much time, but it elevates the quality of the projects I'm working on. So overall I find it worth it to put in the effort to use Docker.
The codebases that you can create nowadays are light years away from what you would see 10 years ago. And the frameworks have improved alongside too.
Maybe read https://stitcher.io posts about the new features since 8.0 to have a grasp of the language changes.
For getting up and running, it saves time. For large projects, it adds leaky abstractions, overhead for each request, a need to upgrade another layer - with poor upgrade compatibility (in our anecdotal case), and very little gain. And it has it's own learning curve, which with modern PHP may be redundant.
Symfony looks better in that it is more of a library and less of a framework, though of course that has its own tradeoffs.
IMO, the weakest part of PHP is the db functions (both PDO and mysqli/postgres)
Edit: I'm talking about the php code being compiled / run by an external process which makes the whole thing staless.
It was a "working" design when people were dropping .php files in ftp folder on some hosting provider.
That it's stateless, and therefore often deployed with a module or FPM?
What "external" process are you talking about?
This model is imo outdated, why can't we create a PHP server that just runs without the need of something external.
Also, I'll not pick any of the interpreted languages for that matter and would want Golang/Crystal/Nim to get single binary to be packaged.
But of course - this isn't necessarily something everyone would do.
There are no right or wrong answers here I suppose.
Web or something else?
I ask because I haven't heard many using Crystal/Nim for web.
That being said, one issue I've found is that while I can use VSCode for every other language, using PHP feels terrible if I'm not using a JetBrains IDE. I tried installing the PHP extension pack, but it was still leagues behind. Is there any guide someone can recommend for making PHP a first-class language in VSCode, or am I stuck in phpStorm?
It's possible that PHP's ubiquity and the core language's poor architecture/design (for decades now) are the source, not the ignorance of those complaining. PHP was the very first programming language I learned, in 1997. If anything, I mostly stopped disparaging it because I simply moved on in my career enough to be able to choose languages that aren't constantly fighting me.
I'm a consultant so I get asked about unfucking PHP codebases every few years, and I check in on the ecosystem and language. It's better but (unsurprisingly) still not great. Meanwhile, languages a decade+ younger avoided PHP's mistakes.
PHP supported versions - https://www.php.net/supported-versions.php
Edit for context: the small business that I work for takes on all kinds of random web work. It's not uncommon at all for us to be asked to rescue an application or website that's still running on PHP 5. For projects that we have initiated, by the time we migrate them all to PHP 8.2, it will be End of Life.
1. Compile PHP yourself (no)
2. Use an untrusted third party repo (probably not)
3. Upgrade OS to latest
4. (apparently) Use FreeBSD instead.
For all I know this could change. The current release schedule of PHP is greatly accelerated from what it was 5-10 years ago, and we're all still adjusting I think.
If you can't trust Ondřej Surý's repo, you're gonna be disappointed when you see who maintains the PHP packages in Debian's official repo.
It's just like the Rust folks never miss any chance to bash C++, while C++'s market share keeps rising and after 16 years since Rust was created, it can not even make 1% of the market while C++ is 12%(excluding C which is 16%,again it keeps rising).
Rust's goal by the way should just replace Ada for specific areas, to take on C++ on a broader level it probably needs another few decades, if it can ever make it that is.
It's also not a contest? I'm not sure why people care about these numbers. PHP keeps getting bashed because it's a bad programming language full of footguns, then and now, regardless of whether or not other programming languages exist.
how is it 16 years when Rust 1.0 was released in 2015?
[1]: https://wiki.php.net/rfc/deprecate_dollar_brace_string_inter...
`words ${var} more words`
I thought we would start seeing more usage of this in PHP to make things more consistent.
I imagine it might crop up for people that also use Perl, since that would be more common there, like:
$foo="abc${var}def";
Kinda odd that Bash has had this syntax since forever, Perl as well, JavaScript went out of its way to add it as well, and now php is like: let's remove this syntax specifically but allow typo variants of it!
Oh well. Not like I was using it, that is, I use the bare "$foo" syntax and try not to make string interpolation too complicated with inline expressions or some such. Just, I could have seen the logic behind switching to the more universally supported syntax and deprecating something else rather than doing their one-off thing.
I'll also point out that in shell assignment looks like
a="foo"
$a="foo"
return self::CONSTANT; // Fatal error
however that is actually allowed, what is an fatal error is
return Foo::CONSTANT; // Fatal error
compare
https://3v4l.org/dIeOk#v8.2rc7
https://3v4l.org/11of1#v8.2rc7
Prohibit direct access through a trait name
As per how to select versions easily, the Symfony project provides a Symfony CLI and one of the features it provides is checking for a `.php-version` file in the current directory and selecting the correct php binary from the PATH accordingly.
I use that when I'm dealing with projects on different versions.
Well that's the thing: I don't know anyone who actively develops in Ruby, Python, Perl or Node that uses the OS-packaged runtimes. The system packages and the language-specific package managers live in different universes.
I've seen this situation blamed on both OS packagers or language ecosystems, but now I just think the goals between the two just are fundamentally at odds.
I hate language-specific package managers. I can see their value to packagers (less work), but they end up arguing with the platform package manager.
It's like there's a load of CS graduates churning out lots of new, better languages; but what's really needed is just one better language. Similarly we have a score of new package managers, creating incompatibilities; so we add some more package managers, to paper over the incompatibilities.
I'm inclined to the view that perhaps there are too many coders in the world, creating compilers and package managers because they can't get a job doing something useful.
https://www.reddit.com/r/linux/comments/nnxng/petition_lenna...
You _can_ use PHP from the command line but it's not the same kind of thing as Python or other languages where you need to be mindful of which version some shell script might assume is installed, etc..
That is for all but one version that is compiled from sources.
Note: I think PHP is way under appreciated.
Like the poster above: I totally support PHP ... it is good, it has surprisingly well aged in the recent years, and it perfectly has its place ... but it has warts. Nothing bad, nothing tooling could not compensate ... but there are warts because of its origin.
Other languages has warts too: Java has no real generics, Python has it when you do indenting wrong and let us not start on JavaScript or god forbid VisualBasic. As a C# fanboy, i have to rely on others to see warts there ;)
They'd gather back my respect when they get rid of all the moronic behavior they have in the functions of their global namespace
* Like sleep that returns 192 on windows but not on linux when you interrupt it
* hash_hmac that if you pass array to $data, php will generate a Warning, return a NULL and continue, I'll let you imagine how bad this is in the context of hmacs when null gets typecast to 0 later on
* etc
Increased strictness in the types that can be passed to the built-in functions has been a general area of focus for the last several versions.
The thing is that PHP is (was) a good example of bad language design. It's original creator is (was) also known for its total disdain for "correct working software". The language and standard library even more show this quite clearly.
See reddit.com/r/lolphp for a community dedicated to bringing PHP's bad design pearls to the surface.
* function autoloading
* typedef
* templating hooks for escaping output and such
* better phpdoc, e.g define class without creating class, nested structures.
* inner class
* modules (instead of namespaces)2. Officially supported runtime that exposes system event loop to userland (yes, we have swoole and roadrunner)
EDIT: have you looked at ngx-php. It’s blazing fast and provides you that event loop.
That's something up for debate. Personally, I'd like the shared-nothing approach but I'd like to have async capabilities to optimize I/O and a function that flushes the request and frees up resources for next request in queue.
edit: I haven't seen ngx_php, thanks for the link!
It has some nice things but for everything in PHP, there other languages that do it a lot better. And I don't think CGI is a killer feature in 2022, it doesn't matter anymore than any other implementation detail, and causes more problems than it solves.
there is symphony/laravel as web frameworks, which by all accounts are modern and highly usable, but that in itself doesn't distinguish php given how many alternatives exist
The major niche has been carved long ago. Low cost code for budget conscience clients. PHP has long been the easiest on-ramp to webdev for many folks and some of the things out of it Wordpress specifically, can be utilized to cover a vast number of rather low complexity needs. If you consult with budget conscience clients, you likely find PHP indispensable. If you (or your employer) are building your own software product, you care more about DX and such and have chosen something else. In both scenarios, the end users of the product do not give a damn what it was built with.
But you can use strict_types! With strict types, PHP 8+ is a very nice language.
I challenge you to find PHP deployed in production in any Amazon service