AS far as I know, this is because it was and still is common practice to return a result from a function, but return false if something didn't work. Having this type helps return type declaration like: false|ResultObject
In my opinion, using Exceptions or nullable types is a better practice in those cases, but I am not against having more options.
Yeah it makes a lot of sense just to be able to type existing functions. Seems weir d not to allow true though. I feel like both should be added for completeness.
I don't mind a unit type for failure. I just don't think it should be called "false". Maybe make true and false Boolean and have a unit type for failures called "fail" or "failure".
I think for new code Exceptions are the preferred solution in case your code errors out , much more clear to return just one type of data. So this seems to be just a solution for improving type declaration for older code that that use the pattern to return false in case of error instead of an exception with a much more clear information on what went wrong.
Right, in the context of PHP it makes sense, as bool would imply you might need to handle a truthy value when in reality the return type of several built-in functions is result|false.
Nullable types generally work well, unless you're you have a function that may return nothing, or an error. IE findUser(string $name): ?User wouldn't be able to differentiate between a database error or just not finding a user with that name. Exceptions would work fine here (specifically due to a DB error), but seem a little superfluous for smaller functions.
Personally, I've grown to love the tuple return types of Go/Rust, and I'd love to see first-class support for that within PHP. You can emulate it by returning an array and unpacking it / using list(), but it adds a decent amount of boilerplate and you lose aspects of type covariance in always returning an array.
The site doesn't make it clear, but this isn't a full list, since PHP 8.2 will be accepting RFCs until mid-July (see https://wiki.php.net/todo/php82 for the release timeline).
Even though it's incomplete, this page helps to generate excitement about PHP generally, which is a good thing — the PHP community sometimes struggles with its reputation as a dying language.
I think those can both be true. For instance, Google Trends[0] shows interest in it falling significantly with time. However, Wordpress is written in it, so a lot of people are still running PHP on their servers.
I wonder if PHP:Wordpress is becoming like Ruby:Rails, where there’s no reason you can’t use the language for other things, but in practice it’s mostly used for one specific purpose?
It's not only Wordpress. There's also Drupal, Joomla and the myriad of plugins written for them, as well as forums software like Vanilla, phpbb and vBulletin. Actually, I predict a resurgence in forum software popularity as more people realize Reddit is for suckers; there is of course Discourse, but that's like New Reddit, looks cool until you use it and realize it's kinda shit.
Those are rounding errors compared to WordPress[0]. BTW, I'm neutral on WP. I've used it before and it was fine, but I don't work for Automattic or anything. I think it's the elephant in the PHP room, though. No one can claim that PHP is only used for WordPress, but I bet that the majority of PHP installations are there because that's what WP happens to be written in.
I don't think it's exactly synonymous with market share.
The numbers are a bit distorted due to a few "killer apps" like Wordpress. I think if you looked at it in terms of number of developers using a language then it will have fallen quite precipitously.
Dying is an exaggeration anyway, I think PHP is just no longer in it's glory days of the 00s.
I'm personally hopeful that PHP might have a renaissance. The language developers have done a really good job of modernising it and removing the really nasty stuff over the last ~7 years, I think it's just the standard library that's left as a significant eyesore. Unfortunately Nikita's stepped down from PHP development recently and he was a real powerhouse so it remains to be seen if it can maintain its trajectory.
I started using PHP in 1999 and it was my main language until 2011. But PHP no longer has the advantages that made it outstanding back in 1999. Other languages caught up and moved ahead. When I need a dynamic language, I'd rather program in Clojure, and when I need strict types, I'd rather work with Java, which is much easier to get going nowadays than it was back in 1999.
PHP has Wordpress, in the same way Ruby has Rails. In both cases, the languages survive because they've got at least one great killer app. But both languages have stagnated relative to the developments that happened elsewhere. Circa 2000 it was as obvious as the sun is bright that PHP was the easiest way to program for the Web. Nowadays it is a royal pain.
The one place where PHP still has use for me is when I need to write a small server script: I'd rather use PHP than bash. But this is a very small use case.
That's pretty big one. Lot of JSON can be deserialized to basically bunch of objects with dynamic properties, since it's parameter in deserialization.
For example `json_decode("...", false)` where second parameter (false) explicitly says it should return object. After that it's typical to set values such as `$post->name = 'Name';`, which would now give warning and in PHP 9 an error.
Maybe we shouldn't characterize PHP as dynamic language after the change?
Classes marked with #[AllowDynamicProperties] as well as their children can continue using dynamic properties without deprecation or removal. The only bundled class marked as #[AllowDynamicProperties] is stdClass.
Aka stdClass based obj's are still fine to have dynamic properties. So mostly sure it's still going to work.
json_decode('...', false) will deserialize into a stdClass - which I guess implements magic methods __set() and __get. I've never checked this but I guess that would do the trick has mentioned in the article itself.
stdClass doesn't implement magic methods -- any properties you add are added directly to the object, not to any kind of internal data store -- but it is explicitly marked as an exception to the proposed rule.
I always wondered why you want to deserialize JSON as ab object tree instead of associative array. Just because the syntax is nicer? I mean, your ide still can't autocomplete the fields for you since it's just a stdclass and it doesn't know anything about the JSON structure right?
Also, probably not relevant in practice, but one of those two is probably faster?
You can get an associative array with one more parameter, so that's what I do. Array access is nicer than object access to me, but maybe that's just me.
One important difference is how you will pass the decoded JSON data afterwards within your application, objects are passed as reference and arrays are passed as copy on write, thus if you intent to modify it it can be easer with an object.
Another is if you going to merge JSON data and send it further then an object can be easier because that is how the rest of the world views it.
However there many more array functions in the standard library than object functions.
I think it is generally easier to annotate arrays vs objects with phpdoc.
If this blog post is still true today when it was written (2018 PHP 7.2), then arrays are better for performance vs stdClass, but a real class is better than both, but sadly you can't JSON decode into a class directly.
Arrays probably offer a better memory management experience. It’s probably way easier to accidentally close over the json object in a closure than an array. But if you want “spooky action at a distance”, objects are the way to go.
The last few years have brought insane progress to the PHP language. I absolutely love the direction. Personally, the next feature I'd like to see the most is a great implementation of Tasks / Asynchronously, something the language always lacked, possibly because it is nearly exclusively used with web servers. I mostly get around that by extensively using queues, software like RabbitMQ, and spawning micro services. I would like to see it move towards more general purpose usability.
Fibers don't run concurrently with the main thread. They're like preemptive multitasking, not simultaneous multitasking.
For example, if you have a long-running database query, disk I/O, or some other blocking function, you can't simply send it to the background and do something else while waiting for the result. Network requests are better, but only because the underlying functions support a rudimentary form of async calling.
PHP seriously needs an event loop. The Node model, where things that call into libuv to wait on servers and such prevent the script from exiting, is simple enough to implement and while mildly unintuitive to newcomers is still accessible thanks to Node's popularity.
As long as from the programmer's perspective it's opt-in rather than opt-out—that is, "await" by default. That was a huge mistake for Node and will seemingly haunt it forever.
If anything the NodeJs model is trickier to scale because it requires discipline to never block the loop unnecessarily.
PHP/Go/C# one-thread-per-HTTP-request also requires less cognitive load where everything is synchronous by default. Also PHP's throw-away-everything after each request tolerates much more junior-code abuse.
Forgot to close a database connection or transaction? No problem, PHP will do that for you. Left a file open? Forgot to close a CURL handle? No worriers the janitor is coming to clean your mess at the end of the request.
With that said, PHP does have an event loop. See ReactPHP and Swoole. They existed for years and while they have their uses, they aren't going to overtake "standard" PHP execution model anytime soon partly because of the reasons above.
PHP is currently my favorite language to work in, especially as a freelancer who needs to just get things implemented quickly. No strange docker log issues like I've had with python/node stacks of errors not showing in docker logs until a service restart; just reload a page and bam.
It sounds like they're talking about deployments where a new process is spawned to handle each request, but for the most part no one deploys Python web apps that way, so I'm not sure.
PHP may have some advantages in terms of deployment, so I guess it's a question of whether those advantages outweigh the potential advantages of using Python for development, which is of course subjective/situational.
It's because PHP uses a CGI process-per-request style model, while there's no good or modern for support in Python for that execution model these days (the community is built around WSGI and ASGI instead). Opcode caching isn't actually relevant because PHP reuses the processes and in-memory structures these days as much as possible.
Partially not kidding - I've used this as far back as 2004 to build cron jobs that pull a dataset, split it into N subsets, then fork out into N children to process those subsets of data in parallel. It's certainly not fluid like tasks and it creates a lot of memory duplication if you fork AFTER your data is pulled, but it works surprisingly well. Parent thread can wait for children to finish and even message children through socket pairs (or pcntl_signal for very basic stuff). I agree that it would be nice to have a native abstraction for tasks with messaging and concurrency limits built in.
> The last few years have brought insane progress to the PHP language
I’ve been hearing this for ~20 years, and yet somehow I still find it more painful to use than other languages that didn’t even exist 10 years ago…
(Except for “being easy to deploy on any random bargain-basement shared web host”, which is a hugely important factor where PHP is genuinely best-in-class and no other language even seems to care about competing, and is the reason that I still regularly need to use it)
The real problem with PHP was always the standard library and its many caveats, outright bugs, and inadequacies, rather than the PHP language itself (there's a few language issues as well, but I found those less painful than the standard library).
A few of these things have been fixed, but by and large the situation has remained unchanged for a long time. It's not an easy problem due to compatibility reasons; adding new language features and such is comparatively easy.
This. PHP is PHP just like Javascript is Javascript. Their growth process was a bunch of people needing things and just implementing them one by one without a grand design. It kinda works, but it'll never be Good in a theoretical sense.
Disturbingly for us language geeks, it doesn't seem to matter at all that they're not very good.
PHP has value types - the one "every data structure at once" type gets deep copied when you pass it to another function. That's enough to make it a good programming language, whereas Python is unnecessarily 90s class-based OOP with reference types.
If you have a dictionary and pass it around to someone else's code and it gets changed, those changes affect your code too instead of copying it, which is annoying and less safe.
PHP 8.2 will probably not add many new features more of cleaning up the language (still important ofc), similar to PHP 7.2 or PHP 7.3.
PHP 7.4 did however add a lot of interesting features like FFI, JIT, preloading, typed properties and arrow functions.
Thus if PHP 8 development will by any way similar how PHP 7 was developed you need to hang in there for at least one more release but probably two more releases or wait for PHP 9.
Makes sense. It takes time for new features to get traction and iron out any missing parts that the original RFC didn't think of. Lots of software projects alternate between new-feature releases and cleanup/bugfix/housekeeping releases. Users also like to have a period of stability before they need to change things up again.
Sadly there are a number of functions in the PHP standard library that literally never can return true. Often they return a resource or false, for example. In those cases the `false` type is more accurate than boolean. That's the reason for the distinction.
I don't think the argument is against unit types. I think the argument is against calling one "false", and I agree. If you're going to have a reserved keyword "false", have "true" and "false" as Boolean. If you want a unit type to mean "failed", "failure", "incomplete", or something, use one of those words.
It’s really an announcement about the formalisation of existing API patterns: returning FALSE on failure (regardless of the “success” type) is part of many old php apis, this change allows properly typing those.
It actually makes a bit of sense if you think of Bool as a class instead of a primitive type, and True and False as subclasses of Bool. So a function can either declare its return type as "bool", or as the more specific "false". True is simply not implemented.
PHP isn't exacly an "everything is an object" language, but it's been slowly moving in that direction for years, replacing most callables, resources, etc. with corresponding objects. I wouldn't be surprised if the designers are approaching this issue with an object-oriented mindset, though it still feels wrong to make an exception for only one half of a boolean pair.
This works fine in TypeScript. You can specify a type as boolean, true, or false, and it works exactly as you’d expect. I don’t see an issue with doing the same in PHP
It would not surprise me any to have a Boolean type and have both true and false as restricted subtypes of that. However, in this case of it being used primarily as a return type for failure in a function call, I think they're conflating the tradition from C-style languages of returning a false-ish value in-bound rather than creating a type specific to the error condition.
> I think they're conflating the tradition from C-style languages of returning a false-ish value in-bound
It’s not really conflation when php has been doing that since forever as it originally was little more than a thin shim over C (you can see that in lots of older APIs e.g. the mysql_ stuff is straight transcribed from the C library).
Introducing `false` as a standalone type but not `true` is what makes this weird. Generic, literal returns are fine. Python is another language that has it [1].
The introduction of the RFC [2] also still mentions `false` is of type bool:
> null corresponds to PHP's unit type, i.e. the type which holds a single value. false is a literal type of type bool.
But why call it bool if `true` is not a standalone type too?
Oh, it makes sense. It would just make more sense to me if the unit type for an error or failure was called "error" or "failure". They're sort of overloading the idea of true/false here with the historical baggage of returning a value that evaluates to false-ish for failure, then codifying that in a new type rather than taking the chance to make the new type a clean break from that in-band concept.
What else do you expect, PHP has its roots in a bunch of wrappers around C functions with in-band error signaling. Those functions are like grandpa's old watch that you just can't bring yourself to throw away even though it doesn't match any of your new outfits. Mama WordPress would be mad. :)
On a little more serious note, Perl is an earlier language and even more closely tied to C tradition. Many (but not all) of its built-ins and library functions and methods return undef rather than 0 for failure.
PHP functions don't return 0, either. They return `false` which is easy to distinguish from other false-ish values using the `===` operator. They're still overloading `false` with failure, of course, but it would be unfair to say that PHP conflates all the false-ish values.
It's for backwards compatibility with functions that return either the expected value (maybe an array or a string) or false (never true). So you can use it in a union like `foo(): string|false {}`. In that sense, it's not a boolean because it will only ever be a string or false.
That makes sense, though you would want a linter or something to check that callers are doing "=== false" and not "== false", since falsy (but not false) values would match the latter.
If you're using `==` in 2022 without testing or linting, this would be the least of your problems. Also, with the strict_types declaration, it wouldn't be coerced.
The contextual escaping is very cool (although a little frightening given the complexity of it), but the ergonomics of parsing, nesting, and executing templates is very confusing IMO.
I guess that depends on what you mean by “as you would in PHP”. I assume everyone uses something like Twig these days, so in that case, absolutely. You even get compile time checking from Rust libraries like askama: https://github.com/djc/askama
There is nothing in this blog post nor in the PHP 8.2 release that suggests that PHP 9.0 will be different language and not compatible with previous versions.
Major backward-incompatibility is a huge mistake. Python made it and had 10+ years of a mess with incompatible v2 and v3 code bases confusing and infuriating people.
Now that you put it this way - is this going to be another python 2-to-3 problem? I hope they have some solution to quickly bring everything to the new version; the proposed changes seem reasonable though.
You can of course argue that any major update that breaks backwards combability the slightest is a dialect of the previous version, but that is just silly.
- Looking for PHP 8.2 dialect programmers!
- I have only coded in PHP 8.1 dialect.
- Sorry, won't do.
The changelog tells you want you need to fix on existing code when upgrading and the manual usually gives you a workaround if it is something larger. And in this specific case you just add the attribute #[AllowDynamicProperties] to you dynamic class and be done with it.
Yep, thankfully PHP respects semantic versioning. Much like Python 3 broke 2.x compat, PHP 9 breaks 8.x compat. Although the truly backward compat breaking changes are quite few, and uplifting 8 to 9 will be fairly low effort (and almost certainly something that linting can spot for the vast majority of code bases with near-trivial fixes).
We had to do this when we went from v4 to v5, we had to do this when we went from v5 to v7, we had to do this (but less so) going from v7 to v8, so if having to do this from v8 to v9 as well is suddenly too much work, either you haven't been using PHP for very long, or you took a weird moment to suddenly take exception with codebase migrations. Especially as, of all the version updates so far, 9 promises to be by far the most worth it.
I wish there was a fork of PHP that cleaned up all the things that would break backward compatibly (e.g. have consistently method naming, clean up type casting for methods that do that which can today lead to weird bugs, etc). Essentially, haven't an entire "clean" language to work with.
I was under the impression that even though Hack no longer is backward compatible with PHP - that in practice, it's still largely the same (not much has changed). Or am I mistaken?
Lots of changes. Like built in async, generics, shapes (typed associative arrays) and I learned the other day here on HN that XML templating is built into the language, somewhat similar to JSX.
The most annoying thing you encouter daily in PHP is the needle/haystack problem. There is no consistency with parameters of the standard library. It could be fixed in two ways:
a) Make everything an object, where methods can be called on:
$arr = [];
$arr->key_exists('key');
b) Create a new class-based standard library, where you call those functions statically and needle/haystack are always in the same place:
Arr::key_exists($arr, 'key');
Either way, you can deprecated all the array_..., str_..., etc. functions and end the guessing game. Other than that PHP is turning out great.
There is actually some consistency, array functions have the same parameter order and string functions have theirs, it just different order between these two groups of functions.
Laravel’s “Collections” library [1] solves this, and is a breath of fresh air. Easily one of the best features of the framework (though you can also use it as a separate package, outside of a Laravel app [2]).
It’s simple to use, but extremely powerful. I pretty much always use Collections over native array functions these days.
I am sure that if you use a language/library for long enough, its bad design descisions aren't a huge problem to you.
Reading the docs of course helps, but it is still inconvenience and waste of time to check inconsistent parameter order and function naming from docs. I don't understand why people are so keen on defending these things.
Is there any programming language that changed so much as people that know the initial versions will not be able to understand the latest one? This is my impression about PHP and I cannot remember a single other such case. My memories go back to the 80's (Basic, Pascal, Cobol, SQL), I am not familiar with the current state of C, but my feeling is that the latest PHP and the original PHP share little more than the name.
It's entirely possible. I wrote my last real PHP in 2014. Even then I was maintaining a very old app. I did write a quick API in Laravel back in 2017 just to see what all the fuss was about. And even then. PHP felt a LOT different.
I keep an eye on the language and I'll admit, it's VERY far from what I originally used. That's a good thing.
Perl changes a lot; I'd say C++ changes a lot, but they just constantly add stuff without removing much or caring how easy it is to make dangerous mistakes in it.
"PHP used to be a very dynamic language, but has been moving away from that mindset for a while now."
For gods sake, if I want a stricter language, then I will use a stricter language. I've used Java for many things, I've used Scala for one large project, and PHP will never be able to compete as a strict language. I don't understand why language maintainers would decide "People love this language, but let's try to transform it into a different language."
I've the same criticism of Python, I think it should have continued with the design goals and philosophy of 2.x, I think the attempt to become more object oriented was a mistake, I think 3.x was a mistake. There was a philosophical cleanness in 2.x that is missing in 3.x.
Some language communities suffer a crisis of confidence and then they try to become something else, but this is always a mistake. As we saw with the transition from Python 2.x to 3.x, it takes 10 years to transition a language community, and meanwhile a developer can simply learn a new language in 6 to 12 months. That is to say, the developers can adjust much more quickly than the language, so each language should try to stay true to its original vision. Borrowing some good ideas from other communities is fine, so long as a clean implementation can be envisioned. But taking a language that was famous and adored for its sloppiness and dynamicness and then trying to make it strict? This is a bad idea.
I agree, but at the same time I've lived the PHP transformation as a professional developer and I think I know the reasoning.
Maintainers and supporters of a language are usually people that are professionally very invested in the language. And therefore it's natural for them to steer the language towards fixing their pains first and foremost.
And anyone who's been invested into a language for a long time, with lots of old code to improve and maintain, an enormous muscle memory for all things related to the language, thousands of snippets, patterns and libraries in your tool belt, knows that changing languages is not trivial.
For someone directly involved into the language governance, it's actually easier to change the language.
Even if that goes against the languages original spirit.
Honestly, I'm a little sad about PHP's direction. What I enjoyed most about it was it's simplicity. It seems like at this point everyone is trying to add $everything_i_like_about_java and $everything_i_like_about_javascript etc. It's almost like this is "phpng" now.
I've always dreamt of a purely procedural PHP fork, removing all the overhead for object management. Keep things as functions, arrays, and I'm even cool with type juggling. Fix the needle/haystack stuff, but basically a "scripting" layer relatively close to being on top of C, in a way. I can do a ton of amazing things without the need of OOP/objects/autoloaders and basically anything else introduced after PHP 5.x. :)
142 comments
[ 2.6 ms ] story [ 212 ms ] threadIn my opinion, using Exceptions or nullable types is a better practice in those cases, but I am not against having more options.
Nullable types generally work well, unless you're you have a function that may return nothing, or an error. IE findUser(string $name): ?User wouldn't be able to differentiate between a database error or just not finding a user with that name. Exceptions would work fine here (specifically due to a DB error), but seem a little superfluous for smaller functions.
Personally, I've grown to love the tuple return types of Go/Rust, and I'd love to see first-class support for that within PHP. You can emulate it by returning an array and unpacking it / using list(), but it adds a decent amount of boilerplate and you lose aspects of type covariance in always returning an array.
Even though it's incomplete, this page helps to generate excitement about PHP generally, which is a good thing — the PHP community sometimes struggles with its reputation as a dying language.
“PHP is the most used server-side programming language globally”
https://kinsta.com/php-market-share/
I wonder if PHP:Wordpress is becoming like Ruby:Rails, where there’s no reason you can’t use the language for other things, but in practice it’s mostly used for one specific purpose?
[0] https://trends.google.com/trends/explore?date=all&geo=US&q=%...
[0] https://w3techs.com/technologies/overview/content_management
What do you recommend instead?
The numbers are a bit distorted due to a few "killer apps" like Wordpress. I think if you looked at it in terms of number of developers using a language then it will have fallen quite precipitously.
Dying is an exaggeration anyway, I think PHP is just no longer in it's glory days of the 00s.
I'm personally hopeful that PHP might have a renaissance. The language developers have done a really good job of modernising it and removing the really nasty stuff over the last ~7 years, I think it's just the standard library that's left as a significant eyesore. Unfortunately Nikita's stepped down from PHP development recently and he was a real powerhouse so it remains to be seen if it can maintain its trajectory.
PHP has Wordpress, in the same way Ruby has Rails. In both cases, the languages survive because they've got at least one great killer app. But both languages have stagnated relative to the developments that happened elsewhere. Circa 2000 it was as obvious as the sun is bright that PHP was the easiest way to program for the Web. Nowadays it is a royal pain.
The one place where PHP still has use for me is when I need to write a small server script: I'd rather use PHP than bash. But this is a very small use case.
That's pretty big one. Lot of JSON can be deserialized to basically bunch of objects with dynamic properties, since it's parameter in deserialization.
For example `json_decode("...", false)` where second parameter (false) explicitly says it should return object. After that it's typical to set values such as `$post->name = 'Name';`, which would now give warning and in PHP 9 an error.
Maybe we shouldn't characterize PHP as dynamic language after the change?
> stdClass and __get/__set are not affected by this change.
Your json example, or object cast of an array, or directly defining properties on a stdClass will not cause a deprecation.
Aka stdClass based obj's are still fine to have dynamic properties. So mostly sure it's still going to work.
You can also still implement the __get/__set methods on the class to have dynamic properties.
What this RFC does is to remove not declared dynamic properties.
https://wiki.php.net/rfc/deprecate_dynamic_properties
This is only for cases where you have a specific class like User, and you don’t want people setting random dynamic properties on it.
If you do you can also mark the class with an annotation to allow dynamic properties.
Also, probably not relevant in practice, but one of those two is probably faster?
Another is if you going to merge JSON data and send it further then an object can be easier because that is how the rest of the world views it.
However there many more array functions in the standard library than object functions.
I think it is generally easier to annotate arrays vs objects with phpdoc.
If this blog post is still true today when it was written (2018 PHP 7.2), then arrays are better for performance vs stdClass, but a real class is better than both, but sadly you can't JSON decode into a class directly.
https://steemit.com/php/@crell/php-use-associative-arrays-ba...
defined object > dynamic object > array
But it's very much a micro-optimization.
To prevent [] and {} from both being deserialized to an empty array.
By that definition, Smalltalk isn't a dynamically typed language. Neither is Clojure.
That is obviously complete nonsense.
A dynamically typed language is one where types are resolved at runtime. That doesn't mean it can't have restrictions.
For example, if you have a long-running database query, disk I/O, or some other blocking function, you can't simply send it to the background and do something else while waiting for the result. Network requests are better, but only because the underlying functions support a rudimentary form of async calling.
https://www.reddit.com/r/PHP/comments/u80gyg/true_coroutines...
PHP/Go/C# one-thread-per-HTTP-request also requires less cognitive load where everything is synchronous by default. Also PHP's throw-away-everything after each request tolerates much more junior-code abuse.
Forgot to close a database connection or transaction? No problem, PHP will do that for you. Left a file open? Forgot to close a CURL handle? No worriers the janitor is coming to clean your mess at the end of the request.
With that said, PHP does have an event loop. See ReactPHP and Swoole. They existed for years and while they have their uses, they aren't going to overtake "standard" PHP execution model anytime soon partly because of the reasons above.
PHP may have some advantages in terms of deployment, so I guess it's a question of whether those advantages outweigh the potential advantages of using Python for development, which is of course subjective/situational.
I think you miss out if you feel that this is a win when doing PHP.
Partially not kidding - I've used this as far back as 2004 to build cron jobs that pull a dataset, split it into N subsets, then fork out into N children to process those subsets of data in parallel. It's certainly not fluid like tasks and it creates a lot of memory duplication if you fork AFTER your data is pulled, but it works surprisingly well. Parent thread can wait for children to finish and even message children through socket pairs (or pcntl_signal for very basic stuff). I agree that it would be nice to have a native abstraction for tasks with messaging and concurrency limits built in.
A quick test got me 50k req/s HTTP "hello world" on my laptop.
The madlad even managed to place PHP in top 22 TechEmpower benchmark: https://i.imgur.com/6fKUpbV.png
I’ve been hearing this for ~20 years, and yet somehow I still find it more painful to use than other languages that didn’t even exist 10 years ago…
(Except for “being easy to deploy on any random bargain-basement shared web host”, which is a hugely important factor where PHP is genuinely best-in-class and no other language even seems to care about competing, and is the reason that I still regularly need to use it)
A few of these things have been fixed, but by and large the situation has remained unchanged for a long time. It's not an easy problem due to compatibility reasons; adding new language features and such is comparatively easy.
Disturbingly for us language geeks, it doesn't seem to matter at all that they're not very good.
PHP 7.4 did however add a lot of interesting features like FFI, JIT, preloading, typed properties and arrow functions.
Thus if PHP 8 development will by any way similar how PHP 7 was developed you need to hang in there for at least one more release but probably two more releases or wait for PHP 9.
That's just wrong. Boolean is the type. False is just one possibile value of that type.
PHP isn't exacly an "everything is an object" language, but it's been slowly moving in that direction for years, replacing most callables, resources, etc. with corresponding objects. I wouldn't be surprised if the designers are approaching this issue with an object-oriented mindset, though it still feels wrong to make an exception for only one half of a boolean pair.
It’s not really conflation when php has been doing that since forever as it originally was little more than a thin shim over C (you can see that in lots of older APIs e.g. the mysql_ stuff is straight transcribed from the C library).
The introduction of the RFC [2] also still mentions `false` is of type bool:
> null corresponds to PHP's unit type, i.e. the type which holds a single value. false is a literal type of type bool.
But why call it bool if `true` is not a standalone type too?
[1] https://docs.python.org/3/library/typing.html#typing.Literal
[2] https://wiki.php.net/rfc/null-false-standalone-types
On a little more serious note, Perl is an earlier language and even more closely tied to C tradition. Many (but not all) of its built-ins and library functions and methods return undef rather than 0 for failure.
Having false and true be singleton types is perfectly cromulent.
That's how Smalltalk has been doing it for 40 years, and why it can do without control structures:
This isn't necessarily a bad thing, but it does mean that a lot of applications are going to be stuck on old versions.
For my part... I think this will make me fully abandon PHP and just rewrite old apps in other languages, like Go and Rust.
https://pkg.go.dev/html/template (for Go)
The contextual escaping is very cool (although a little frightening given the complexity of it), but the ergonomics of parsing, nesting, and executing templates is very confusing IMO.
Can you elaborate on this?
How did you come to that conclusion from that post?
It'd be more accurate to say 9.0 is a dialect, rather than a wholly separate language.
We had to do this when we went from v4 to v5, we had to do this when we went from v5 to v7, we had to do this (but less so) going from v7 to v8, so if having to do this from v8 to v9 as well is suddenly too much work, either you haven't been using PHP for very long, or you took a weird moment to suddenly take exception with codebase migrations. Especially as, of all the version updates so far, 9 promises to be by far the most worth it.
I wish there was a fork of PHP that cleaned up all the things that would break backward compatibly (e.g. have consistently method naming, clean up type casting for methods that do that which can today lead to weird bugs, etc). Essentially, haven't an entire "clean" language to work with.
a) Make everything an object, where methods can be called on:
b) Create a new class-based standard library, where you call those functions statically and needle/haystack are always in the same place: Either way, you can deprecated all the array_..., str_..., etc. functions and end the guessing game. Other than that PHP is turning out great.And IDEs completely solve the problem of knowing parameter orders by hinting them as you type the functions.
This really isn't that big of a deal.
https://wiki.php.net/rfc/named_params
Except when they have different order :)
It’s simple to use, but extremely powerful. I pretty much always use Collections over native array functions these days.
[1] https://laravel.com/docs/9.x/collections
[2] https://github.com/illuminate/collections
Even before auto-completion I guess I would just read the docs.
To each his own I guess.
Reading the docs of course helps, but it is still inconvenience and waste of time to check inconsistent parameter order and function naming from docs. I don't understand why people are so keen on defending these things.
Introducing false and null loving it :D
Not a dig against sticher.io, love their to the point descriptions.
https://stackoverflow.com/a/55143445
Laravel has pipelines, but it's not generically useful for existing functions. https://dev.to/abrardev99/pipeline-pattern-in-laravel-278p
I keep an eye on the language and I'll admit, it's VERY far from what I originally used. That's a good thing.
For gods sake, if I want a stricter language, then I will use a stricter language. I've used Java for many things, I've used Scala for one large project, and PHP will never be able to compete as a strict language. I don't understand why language maintainers would decide "People love this language, but let's try to transform it into a different language."
I've the same criticism of Python, I think it should have continued with the design goals and philosophy of 2.x, I think the attempt to become more object oriented was a mistake, I think 3.x was a mistake. There was a philosophical cleanness in 2.x that is missing in 3.x.
Some language communities suffer a crisis of confidence and then they try to become something else, but this is always a mistake. As we saw with the transition from Python 2.x to 3.x, it takes 10 years to transition a language community, and meanwhile a developer can simply learn a new language in 6 to 12 months. That is to say, the developers can adjust much more quickly than the language, so each language should try to stay true to its original vision. Borrowing some good ideas from other communities is fine, so long as a clean implementation can be envisioned. But taking a language that was famous and adored for its sloppiness and dynamicness and then trying to make it strict? This is a bad idea.
Maintainers and supporters of a language are usually people that are professionally very invested in the language. And therefore it's natural for them to steer the language towards fixing their pains first and foremost.
And anyone who's been invested into a language for a long time, with lots of old code to improve and maintain, an enormous muscle memory for all things related to the language, thousands of snippets, patterns and libraries in your tool belt, knows that changing languages is not trivial.
For someone directly involved into the language governance, it's actually easier to change the language.
Even if that goes against the languages original spirit.
I've always dreamt of a purely procedural PHP fork, removing all the overhead for object management. Keep things as functions, arrays, and I'm even cool with type juggling. Fix the needle/haystack stuff, but basically a "scripting" layer relatively close to being on top of C, in a way. I can do a ton of amazing things without the need of OOP/objects/autoloaders and basically anything else introduced after PHP 5.x. :)
- "damn kids get off my lawn!"