5 ms·

> Deprecate dynamic properties That's pretty big one. Lot of JSON can be deserialized to basically bunch of objects with dynamic properties, since it's paramet

> Deprecate dynamic properties 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?

mhitza 4y ago
From the RFC https://wiki.php.net/rfc/deprecate_dynamic_properties https://wiki.php.net/rfc/deprecate_dynamic_properties > 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.
coolgoose 4y ago
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.
wackget 4y ago
Yeah this seems like a bad one to me.
tored 4y ago
It is only for classes not for objects (stdClass). You can mark a class with the attribute #[AllowDynamicProperties] to allow dynamic properties. 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 https://wiki.php.net/rfc/deprecate_dynamic_properties
thinkindie 4y ago
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.
- kijin 4y ago
  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.
GeneralTspoon 4y ago
This won’t affect that case, as it uses stdClass (which is allowed to use 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.
iforgotpassword 4y ago
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?
- toast0 4y ago
  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.
- tored 4y ago
  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. https://steemit.com/php/@crell/php-use-associative-arrays-basically-never https://steemit.com/php/@crell/php-use-associative-arrays-ba...
  - withinboredom 4y ago
    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.
- lambic 4y ago
  As far as speed is concerned (and yes this is a generalization): defined object > dynamic object > array But it's very much a micro-optimization.
pwdisswordfish9 4y ago
Indeed, I've noticed a while ago it's slowly becoming a Java with lots of dollar signs.
masklinn 4y ago
> Maybe we shouldn't characterize PHP as dynamic language after the change? 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.
- igouy 4y ago
  Seems to me that we define dynamically typed languages by what they are not — they are not statically type checked.

mhitza 4y ago

From the RFC https://wiki.php.net/rfc/deprecate_dynamic_properties https://wiki.php.net/rfc/deprecate_dynamic_properties > 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.

coolgoose 4y ago

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.

wackget 4y ago

Yeah this seems like a bad one to me.

tored 4y ago

It is only for classes not for objects (stdClass). You can mark a class with the attribute #[AllowDynamicProperties] to allow dynamic properties. 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 https://wiki.php.net/rfc/deprecate_dynamic_properties

thinkindie 4y ago

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.

kijin 4y ago
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.

GeneralTspoon 4y ago

This won’t affect that case, as it uses stdClass (which is allowed to use 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.

iforgotpassword 4y ago

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?

toast0 4y ago
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.
tored 4y ago
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. https://steemit.com/php/@crell/php-use-associative-arrays-basically-never https://steemit.com/php/@crell/php-use-associative-arrays-ba...
- withinboredom 4y ago
  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.
lambic 4y ago
As far as speed is concerned (and yes this is a generalization): defined object > dynamic object > array But it's very much a micro-optimization.

pwdisswordfish9 4y ago

Indeed, I've noticed a while ago it's slowly becoming a Java with lots of dollar signs.

masklinn 4y ago

> Maybe we shouldn't characterize PHP as dynamic language after the change? 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.

igouy 4y ago
Seems to me that we define dynamically typed languages by what they are not — they are not statically type checked.