I've used PHP for almost 15 years and didn't know this was possible. I only added dynamic properties for stdClass. So I guess I'm happy that something I don't use is deprecated.
I would not say that I used them a lot, but it was extremely useful to have them when needed. It made the object very agile. I like to work with object as a result from the dB. And aggregating associated data's together in one object with dynamic property added from the main object was a cool feature that never cause any trouble to my code or users.
I never used this because I learnt computer science using Pascal, C, C++, Java, C#, etc. All those languages required you to think before doing something. I learnt PHP and JavaScript after getting my bachelor degree and I never programmed using dynamic properties. And I hated JavaScript for never knowing what properties an object actually has.
I mean, this is good because it allows you to make certain assumptions about the code. Even allowing the interpreter to store instances using those assumptions. Like using a fixed size storage for efficiency.
I didn't realize stdClass implemented magic getters and setters, I assumed it was just either treated as a special case for dynamic properties or it was annotated with #[AllowDynamicProperties]. Is there any way to tell the difference?
When an application uses Dynamic Properties on a library object (which should not be modified), how would you avoid the deprecation message? Other than rewriting the application, which wasn't broke and fears fixing ;-)
I saw somebody on SO say that this would be the single biggest breaking change to PHP in its history over a year ago, and that it would take out a huge amount of applications. Now 8.2.12 is here it has fulfilled exactly that prophecy for anybody trying to use it with existing code. No longer a warning, now an app killer. Utterly stupid change to the codebase that is going to make many webadmins keep running < 8.2 environments on their servers as the work involved in rectifying the code could be huge on larger projects - which is terrible for security going forward. Stupid, stupid change.
Great idea, being able to abuse your class by just randomly accessing data outside of the class design is just terrible. Would never pass code review in my company.
Год назад+1
Excuse me, but you definitely want deprecation warnings in production, and you absolutely should not be showing any of PHPs error messages to the user whatsoever, so the argument of hiding it from the user is invalid. Deprecation warnings are useful in production because they can catch things you may not have tests for. Log them, and preferably to something better than a text file (Sentry, bugsnag, whatever). And turn off display_errors.
What is improved by this? I would cut off the hands of the person who proposed this barbarity.. // ironic mode Should all languages be same boring / strict? aghh..
I've used PHP for almost 15 years and didn't know this was possible. I only added dynamic properties for stdClass. So I guess I'm happy that something I don't use is deprecated.
Dynamic properties is one of the best thing about php compared to languages like Java. I see it as a stepback
It's just warning, it still works.
@@hmb8801 not anymore. It's an app breaker now in 8.2.12. Hell of a way to ensure webadmins don't use PHP 8.2 + on their servers.
I would not say that I used them a lot, but it was extremely useful to have them when needed. It made the object very agile.
I like to work with object as a result from the dB. And aggregating associated data's together in one object with dynamic property added from the main object was a cool feature that never cause any trouble to my code or users.
This is what most ORM do and I really liked it. Good thing dynamic property is still allowed with stdClass
Makes perfect sense!
I've been waiting for this moment for so long!
I never used this because I learnt computer science using Pascal, C, C++, Java, C#, etc. All those languages required you to think before doing something. I learnt PHP and JavaScript after getting my bachelor degree and I never programmed using dynamic properties. And I hated JavaScript for never knowing what properties an object actually has.
I mean, this is good because it allows you to make certain assumptions about the code. Even allowing the interpreter to store instances using those assumptions. Like using a fixed size storage for efficiency.
I'm a beginner on php and I already have to deal with this issue
I didn't realize stdClass implemented magic getters and setters, I assumed it was just either treated as a special case for dynamic properties or it was annotated with #[AllowDynamicProperties]. Is there any way to tell the difference?
I guess extending stdClass will work in the future version of PHP and AllowDynamicProperties will not
When an application uses Dynamic Properties on a library object (which should not be modified), how would you avoid the deprecation message? Other than rewriting the application, which wasn't broke and fears fixing ;-)
Will #[AllowDynamicProperties] prevent my code to break in the future?
Or it just suppress the warnings for now?
Just to skip the warnings. Although there's no clarity yet if the deprecated dynamic proparties will ever be truly removed
I have PHP 8.2, how come I don't get any warning?
Possibly because you don't have dynamic properties in your code, or because deprecation warnings are configured to silenced.
I saw somebody on SO say that this would be the single biggest breaking change to PHP in its history over a year ago, and that it would take out a huge amount of applications. Now 8.2.12 is here it has fulfilled exactly that prophecy for anybody trying to use it with existing code. No longer a warning, now an app killer. Utterly stupid change to the codebase that is going to make many webadmins keep running < 8.2 environments on their servers as the work involved in rectifying the code could be huge on larger projects - which is terrible for security going forward. Stupid, stupid change.
done error_reporting(0)
Change or die.
@@ecx007 if(change) die();
Ain't it all a bit snobbish ?
Great idea, being able to abuse your class by just randomly accessing data outside of the class design is just terrible.
Would never pass code review in my company.
Excuse me, but you definitely want deprecation warnings in production, and you absolutely should not be showing any of PHPs error messages to the user whatsoever, so the argument of hiding it from the user is invalid.
Deprecation warnings are useful in production because they can catch things you may not have tests for. Log them, and preferably to something better than a text file (Sentry, bugsnag, whatever). And turn off display_errors.
What is improved by this?
I would cut off the hands of the person who proposed this barbarity.. // ironic mode
Should all languages be same boring / strict? aghh..