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?
Aka stdClass based obj's are still fine to have dynamic properties. So mostly sure it's still going to work.
> 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.
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.
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.
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.
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.