Whats New in PHP 8.2
stitcher.io
stitcher.io
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.
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”
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.
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.
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.
function alwaysFalse(): false
{
return false;
}
In 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.
a) Make everything an object, where methods can be called on:
$arr = [];
$arr->key_exists('key');
Arr::key_exists($arr, 'key');
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.
Except when they have different order :)
array_filter(array $array, ?callable $callback = null, int $mode = 0): array
array_map(?callable $callback, array $array, array ...$arrays): arrayIt’s simple to use, but extremely powerful. I pretty much always use Collections over native array functions these days.
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.
Laravel has pipelines, but it's not generically useful for existing functions. https://dev.to/abrardev99/pipeline-pattern-in-laravel-278p
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
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:
Boolean subclass: False [
ifTrue: trueBlock ifFalse: falseBlock [
^falseBlock value
]
"..."
Boolean subclass: True [
ifTrue: trueBlock ifFalse: falseBlock [
^trueBlock value
]
"..."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.
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.
- Looking for PHP 8.2 dialect programmers!
- I have only coded in PHP 8.1 dialect.
- Sorry, won't do.
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'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!"
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.
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.
Not a dig against sticher.io, love their to the point descriptions.
Introducing false and null loving it :D