Recently, while browsing the PHP internals newsgroup, I came across a discussion regarding proposed changes to the language which pointed to https://hive.blog/php/@crell/improving-php-s-object-ergonomics. Having read the article I find myself disagreeing with every point made.
Having started development in PHP as far back as 2002 after 20 years with other languages, and having developed an open source framework called RADICORE with which I has also developed a large ERP application I feel that I am qualified to discuss any so-called "failings" in the language. As none of the "problems" mentioned in the article has ever affected my style of programming I do not regard them as problems at all, and as a follower of the old engineering maxim "If it ain't broke don't fix it" if I don't have a problem then I sure as hell don't need its solution.
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.
If I can achieve complex tasks by writing simple code using the current features of the language then I see absolutely no benefit in making the language more complicated just to suit the personal whims of the Let's Make It More Complicated Than It Really Is Just To Prove How Clever We Are brigade.
Note that when I say "current features" I mean that although my code runs perfectly well under PHP version 7.4 I have not bothered to use any of the additional OO features that were added since PHP 4 for the simple reason that I can't find a use for them. OOP requires nothing more than support for Encapsulation, Inheritance and Polymorphism, and these were covered perfectly well in PHP 4. None of the later versions of the language have offered anything better, just different ways of doing what I have already done, or doing things that I don't need to do at all.
The following responses are directed at the author of this article.
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.
Some people have challenged my statement that PHP does not support value objects. By this I mean that nowhere in the PHP manual does it mention value objects. All values, whether booleans, integers, decimals, dates or strings, are held as simple scalar variables and not value objects. The language does not provide any inbuilt value objects, nor does it provide any classes from which you can create such objects.
When you write values to your database these are provided as scalars, not objects. When you read values from your database these are provided as scalars, not objects. When you write values to your HTML output these are provided as scalars, not objects. When you read values from your HTML form by way of the $_GET or $_POST arrays these are provided as scalars, not objects.
However, there is nothing to stop any developer from creating and using their own value objects, but to me this seems like a total waste of effort. When reading data from either the database or HTML form it is presented in the form of a collection of scalars, so you would have to write your own code to manually move each scalar value into its equivalent object. When sending data to either to either the database or an HTML form you would then have to reverse this procedure by converting each object into its original scalar value. If data comes into and goes out of your software in the form of scalars what benefit is provided by writing additional code to convert these scalar values to and from value objects? Absolutely none! What extra functionality is provided by value objects? Absolutely none! There is no ROI (Return On Investment), so all that effort is wasted because it does not provide any benefit.
I have been told that there is a "need" for value objects when dealing with amounts in multiple currencies as the value object can store both the amount and the currency code. Absolute poppycock! I have been writing such applications for several decades in several different languages where both the amount and the currency code have been stored as separate scalars, so there has been no "need" whatsoever. HTML documents cannot deal with an object which combines both amount and currency as each requires its own separate control. Relational databases cannot deal with an object which combines both amount and currency as each requires its own column. If neither the HTML front end and the SQL back end can handle value objects then where is this "need"?
Here are some other articles I have written on the subject of OOP:
Other comments are available on this reddit post where, as usual, adult debate has given way to childish insults. You can find some of these insults here, here, here and here.
Take note of this post in which a person called zmitic claims to be able to rewrite Radicore using proper methods in just 3 weeks! This I gotta see!