Honest Question: Why did PHP remove dynamic properties in 8.x?
I understand PHP has had many criticisms in the past but I'm not sure the existence of dynamic properties of instantiated objects was ever one of them. In fact, dynamic properties are pretty much the hallmark of most interpreted or dynamic programming languages. Python allows it all the time and so do many others like Ruby, Perl, etc.
I don't know what PHP developers achieved by removing dynamic properties feature from the language but one thing that resulted out of this is that many applications based on widely used veteran PHP frameworks (such as CodeIgniter and CakePHP) came to a halt all of a sudden due to an error like this after upgrading to PHP 8:
A PHP Error was encountered
Severity: 8192
Message: Creation of dynamic property CI_URI::$config is deprecated
Filename: core/URI.php
Line Number: 102
Backtrace:
File: C:\xampp\htdocs\inv_perpus\index.php Line: 288 Function: require_once
The influence of Corporate IT in various open source foundations is pretty well known and also well known is the extent to which corporate greed goes to achieve its interests and objectives across the world. The only way to assuage this uncomfortable thought (at least in this particular case) is to ask if there was any technical merit at all in removing dynamic properties feature from a dynamic programming language?
I for one couldn't find any such merit here.
I've never used PHP myself so I can't really comment on whether it's good or bad, however, I managed to find the original proposal which explains why dynamic properties should be removed:
https://wiki.php.net/rfc/deprecate_dynamic_properties
Basically, they're not trying to completely delete dynamic properties, they're just trying to make them opt-in:
The proposal also goes into more detail about what benefits this has, so you should still read it, it's pretty short
As I said, I'm not a PHP user, but this makes total sense to me. I think accessing a non-existent property is an error most of the times, and it should be reported by your editor as an error. And if you need dynamic properties, you can still opt into using them for a specific class.
I'm also not really sure where you got the idea that Python supports something like this? Maybe I misunderstood what you mean, but python absolutely does not let you access a non-existent class attribute and throws an error if you try to do so. Python is dynamic, yes, but it is a strongly-typed language, unlike something like JS, which does let you access non-existent variables and just returnsundefinedor creates a new field.Python absolutely lets you write to new variables like in the above php example. It will only throw an error if you try to read from one that hasn't yet been created like that.
results in
Alright, I stand corrected on that part. I guess I just assumed it doesn't let you do that because I always use mypy.
I've been using PHP for almost 25 years (12 of them professionally) and I think this is a great change. I encountered many bugs caused by dynamic properties and assume this will improve general PHP code quality quite a bit. Being explicit is a great thing.
In general, I'm super happy with what PHP has become. I don't think the language is as good as Go or other alternatives (and wish typing was stronger or that we could get generics without Psalm), but modern PHP is indeed nice to work with.
Edit: Another thing the proposal mentions is that this will improve static analysis. I think this is very important moving forward, as Psalm, Phpstan, and other tools still miss a lot of (potential) errors.
I'm not totally following here. Are you saying that "Big IT" could have deliberately sabotaged PHP for some reason? Why?
Yes. As long as open source languages like PHP (and frameworks like CodeIgniter) exist, folks will avoid purchasing the costlier proprietary solutions from Big Tech companies, this is especially true for smaller startups and web shops that deal in PHP software like CodeIgniter and Wordpress. The larger aim here might be to cripple the self-sustaining community built frameworks like CodeIgniter as much as possible to make way for Big Tech solutions.
This is... unlikely for at least a few reasons.
It's an easy fix for developer but in this case, production code comes to a standstill the moment they upgrade to PHP 8. Most small-mid apps are production stable, they don't get frequent updates. Unless they specifically ask the developer for an application rewrite (or developer approaches them after knowing this scenario), the client or user would be left standstill with a broken application. Some of them may well decide to bid PHP goodbye and start looking for other solutions?
But life moves on, people leave from one project to another. Do the folks who wrote the original PHP like Rasmus and Zeev Suraski still maintain today's PHP? Perhaps not. And this leaves the door open for corporate interests to put their own agents into high profile projects like these.
Have you heard that famous quote, Life is sometimes stranger than fiction? Many dastardly events often happen on this planet, we just take them for granted. The acquisition of MySQL project by a corporate entity who's interests directly collided with MySQL should have raised all hell! That was one acquisition which should never have seen the green light, in the interests of society and open source culture. IIRC Europe tried its best to prevent that but USA govt. gave the green lights to Oracle eventually.
And don't forget Astrazeneca's recent admission of guilt WRT their famous Covishield vaccine! If the company that now says the vaccine isn't safe, what could have possibly been the motive for it to push them so hard during COVID? Except for corporate greed of the Big Pharma?
All I'm saying is that we shouldn't take these things lightly, they often have a very real impact on human society and civilization and our future.
You don't update production services to a major version of your language/framework/runtime without understanding what you need to change in your codebase, and thorough testing. That goes for all languages.
IMO this change is for the better, and like unkz said, for now it's only deprecated and just a flag away to let you time to update your codebase.
You're quite right here. But that only works when you're hosted on a VPS and have direct control of all package installations including PHP. In case of one of my clients, they were running it on a shared PHP hosting and the provider just upgraded to PHP 8 one fine day without informing anyone!
In this case, the client's application broke along with several others which were using CI3 or CakePHP frameworks. Naturally, the provider soon reverted back to PHP 7 after getting all the distress calls but the impact was done. I guess, the lesson here also comes down to stop using shared PHP hosting?
Yikes. It's been a long while since I've used PHP, but some things never change it seems. Shared hosting goes hand-in-hand with PHP's bad reputation: it's not that the language is necessarily bad, but it's a low-hanging fruit because it's so easy to setup on shared hosting, and then, inevitably and without any intervention of your part, it breaks.
That, or choose a host that does their work correctly and warns its clients several times and months in advance of major updates.
Any sysadmin worth his salt would have looked at v8's patch notes and changelog before pulling that trigger and caught this, it's an obvious major change. Everyone knows that if there is a most appropriate time to be wary of the patch notes it's always the major releases. That's a slapdash shop if it caught their admins by surprise when all the user complaints rolled in. This would make me very likely to abandon the provider. Probably not PHP though. :)
I think this was almost certainly done to improve static analysis and perhaps allow some performance improvements, while reducing errors as a possible side benefit. I'd probably have preferred it to me opt-in and be something more like strict mode in JavaScript to keep it from breaking existing code bases.
JavaScript is executed by the client, while PHP is executed on the server. With JS, you can't control what environment your code will run in - if someone updates their browser, JS gets updated as well, so it needs to have full backwards compatibility, which leads to hacks like
use strictand===. With PHP though, if you don't want to upgrade, you can just not do that. There are still many websites running on PHP 5 or probably even older versions. So it's fine to make breaking changes, especially if they're announced one version prior by adding a deprecation warning.We'll have to agree to disagree on "it's fine to make breaking changes". Sticking with an older and unsupported version of a hosted language is asking for security issues.
Yes, but that's what version numbers mean. The major version number in semver means "there are breaking changes". So if you're upgrading from PHP 8.x to 9.x, breaking changes are to be expected.
Honestly, I am a huge fan of this change. I haven't worked in PHP in a few years, but I did maintain a few business-critical projects that were completely in php for the first 4 years in my current role. I cannot count how many times I made a stupid mistake like this that caused endless headaches and wasted time trying to hunt down. It is part of the reason that my team has committed to migrating all of our PHP and Python projects to Golang. If this change had been made before we had migrated most of our codebase, we might have stuck with PHP.
¯\_(ツ)_/¯ c’est la vie