This article seems to be implying that there are deficiencies in the PHP language which are causing problems for some programmers, and that the language should be changed to eliminate those deficiencies. I disagree with this viewpoint entirely as I consider the real problem to be with the way that some programmers use the language - their choice of programming style - and not the language itself.
An important lesson I learned at the start of my programming career was the KISS principle which can be translated as “A good programmer is one who writes simple code to perform complex tasks, not complex code to perform simple tasks.”
You complain that PHP forces you to write verbose code in your constructor in order to load the object with data, but there is no rule which says that the load operation be performed ONLY in the constructor. There are other ways, better ways, so don’t blame PHP for your poor choice.
You complain that PHP forces you to write too much boilerplate code, in which case I suggest you look at the Template Method Pattern where the invariant/fixed methods are defined in an abstract class and variant/customisable methods are defined in subclasses. In my framework all boilerplate code is defined in the abstract class, which is why I never have to write such code any more.
You complain that there is a problem with value objects, but PHP has never supported such objects, so what is there to complain about? While it is accepted that an object must contain one or more properties and one or more methods, there has never been a rule in OOP that each property within an object must itself be an object. PHP, like so many other languages, uses scalars, not objects, so if you are saying that you cannot write cost-effective software without using value objects, then it is you who should change to a language which suits your preferences, and not PHP which should change to suit you.
You complain that there is a problem with getters and setters, but again there is no rule in OOP which states that each property of an object must be declared separately, and that each of these properties must have its own pair of getters and setters. A relational database deals with datasets where each set contains any number of rows, and each row contain any number of columns, and I have found it far easier to pass this dataset around as a single argument called $fieldarray instead of having to deal with separate methods and arguments for each field with the array. In this way I achieve loose coupling which is far more desirable than tight coupling.
You complain about something called the Materialized Value Object Problem, but yet again that problem is the result of your bad choice and not a fault of the language. It is possible to construct the materialised value within the SELECT query itself, which means that it then becomes just another column in $fieldarray and does not require any additional PHP code to obtain its value.
You complain about something called the Documented Property problem where an object has many properties and some of those properties may be optional. Thus keeping track of which constructor argument is which can become a chore. If you choose to write code where each property has its own argument in a method call then you have to deal with the consequences of your choice. If you now realise that there are problems with the choice you made then you should choose a different option instead of trying to change the language to deal with your poor choice.
You say that there is a problem with immutable objects, but PHP does not support such objects so how can they be a problem? Immutable properties and objects were not specified in any original definitions of OO, or in any early languages which supported OO, so I regard them as an optional extra which were created by someone who thought he was being clever when the result proved to be the exact opposite. I have read several discussions regarding the introduction of immutable objects into PHP, but these discussions identify a large number of complications, and there is never any agreement of how each individual complication can be solved.
Because I consider all these “problems” to be the fault of the programmer and not the language, I consider all of your proposed “solutions” which involve a change to the language to be totally unnecessary. This follows another basic principle which states “Prevention is better than Cure” which means that it is far better to eliminate a disease than to mask its symptoms.
So there you have it. If your choice of programming style causes problems then you should first look into changing to a less problematic style instead of changing the language to deal with your mistakes. Remember that changing the language to suit a particular programming style may have detrimental effects on those you use a more common, simpler and less problematic style.
You claim the problems are not with PHP but with the way people are using it, but I am not convinced you are really offering better ways of using the language as is that bypass these problems.
Specifically about constructors you say there is a better way of loading classes than through there constructor. Um, that is the whole point of a constructor. If there is a need for a better way, that means constructors are flawed and need to be fixed. You also fail to say what that better way is. I don't see how there can be a better way as using anything other than the constructor to finish getting the class into its correct, initial (constructed) state breaks encapsulation and forces you to make poorly designed classes. Properties should be typed as much as possible, and made to not allow null as much as possible. But if after it is constructed, the properties are set to null, this means the type of those properties must be allowed to be null, or else the type is a lie (and PHP will throw an error).
KISS is not something to beat people over the head with. Just because there is not an absolute need for something doesn't mean it is not a real improvement. PHP is continuing to change and evolve. That is not going to change. The community is not about to decide that they will only evolve the language in ways that are absolutely necessary. Instead they have been proposing one RFC at a time, only thinking about if that one RFC is an improvement on its own or not. This could be taking PHP down a dangerous path where they make changes to the language they later want to reverse because they are in conflict with some desirable goal that appears later down the line. At least this article is trying to think ahead and see the bigger picture instead of just tacking on one RFC at a time without a general direction. If you really want to be true to the idea of KISS as you seem to understand it, you should be writing all your code in assembly or some other super low level way, not PHP.
You said, "You say that there is a problem with immutable objects, but PHP does not support such objects so how can they be a problem?" The fact that PHP doesn't support something doesn't mean it is not a problem or that there is no room for improvement. What if PHP didn't support functions or variables, would that mean this is not a problem?
You used the word "complain" seven times and the expression "You complain" six times. He is not complaining, he is writing a serious blog post that he hopes will lead to either himself or other people improving the PHP language (or both working together). You are the one that is complaining.
I disagree. The purpose of a constructor is to leave the object in a state in which it can subsequently respond to calls on any of its public methods. In this context the word "state" means "condition" and not "with data" as in "stateful". Using other methods to load data into the object certainly does NOT break encapsulation nor produce a poorly designed class.
That is just your personal preference and not a concrete rule to which everyone is, or should be, bound. PHP has always been a dynamically typed language and millions of programmers have written millions of programs which have not suffered because of this. I don't have to make any effort to tell the language that a property can have a null value as that is the default value anyway.
I am afraid that what constitutes "improvement" is a matter of opinion, not fact. You may think that changing the language to be strictly typed is an improvement but I do not. I was drawn to PHP in the first place because it was NOT strictly typed, and I have seen my productivity increase because of it. I will not take advantage of the ability to turn on any strict typing option as it would require a great deal of effort to change my existing code base with absolutely no visible reward.
The lack of support for immutable objects is only a problem for those who see a need for immutable objects. I have been writing OO applications since 2003 and I have never seen a need for immutable objects. If they were to become available I would still not use them because I have no need for them.
That'a a silly question. If PHP didn't support functions or variables then I, and probably many others, wouldn't be using it.
He is complaining that PHP does not currently support his programming style and so should be changed. But what about those millions of developers who do not follow the same style? What benefit is there for them if the language is changed? Should they be forced to change their style just to be consistent with him? As far as I am concerned there are many ways in which the components provided by the language can be assembled into meaningful programs, and different programmers have their own personal preferences, their own style. I do not think that the language should be changed to support one style over another, it should allow the developer to adopt whatever style they see fit. In other words it should be "free style" just as it supports both the procedural and object oriented styles without promoting one over the other.