The PHP 7 Revolution: Return Types and Removed Artifacts

While I personally do not have the same view on the changes that is happening in PHP 7.0, I completely agree on that any functionality that is removed should be deprecated first.

At the same time, I do not believe this is what ruin the confidence in the language, what does that is the inter-tangled mess of internal function names, the order of parameters across the internal functions, poor support for multibyte charsets (not all of the internal functions support it) and missing vital data types like Decimal.

We are working with Enterprise solutions as well, and we cannot wait until the new version is released due to massive improvements to the internals, both for the speed increases and making it easier to make extensions. This alone should be enough for anyone to update their code base if they are using any of the functionality that is removed.

I have been called many things, but never a "Pillock" wink

No, no! Just not the recruiters! smile

My apologies, I have no idea how that got past me. I know many males with the name "Toni", so it never seemed out of the ordinary. I have updated the post.

I agree, this should have been addressed by either not removing the functionality, or by marking it as deprecated first. Jumping to removals is not healthy for the language's ecosystem.

But they, the makers of the language, believe they have a good reason. Who is to argue which reason is good and which isn't? The majority? In this particular instance, I objectively believe you are the minority.

One thing I think would be a very important step forward is Scalar Objects to allow $str->replace(), $int->abs(), $array->combine() etc. Is there any discussion about implementing this? There's an extension here: https://github.com/nikic/scalar_objects but it's a bit limited at the moment.

This syntax change could also help fix a lot of the odd naming inconsistencies strpos vs str_replace, etc.

I currently know of no such implementation talks. Would be nice.

If a business needs to run a piece of code, to me this also implies actively maintaining it. TonyM subscribes to the write and forget view which may also be the view of many others, including corporates, but I think that dev paradigm is very risky and short sighted.

Important code, whether it is mission critical or not, should always be in active maintenance. Code which is no longer needed, can be junked, but if any code is still used, even if just once per year, it should be in the active maintenance pool and assigned to one or more coders to keep up to date.

I have my own projects and I actively maintain everything which my business depends on. I also engage in code reviews every 3 months and refactor code if needed.

I do not subscribe to the "if it ain't broke, don't fix it" paradigm. I believe that all code is inherently broken (has bugs) and constant code reviews, refactors, rewrites, are there to eradicate bugs and improve my code.

If the language changes, code must also change. That is the only dev paradigm that makes sense, because progress is a good thing and we should not hinder it.

1 Like

Well I'd really love to see what TomB was saying implemented in PHP 7 or later versions, it bothers me that in PHP strings and arrays are not object. I guess it's impossible to defend against someone from Java/C#/Python/Ruby background when he claims that PHP is a bad OO language, since it is clearly still built upon scalars and objects are not integrated at the core but rather serve as addon or afterthought.

In the framework I currently am developing, string and arrays are objects. I build wrapper classes for these, and strong typing can be enforced. Still, it does not feel natural and the code can suffer 30-50% performance hits. If string and array are treated as objects by default, all the problems will go away. The extension looks really nice and I think it will be faster and consumes less memory than my wrapper/boxing classes, but still it seems that it's not possible to use "str"->toUpper() or [1, 2, 3]->sort(). Its a pity though, but I understand.

That is a really cool idea which many of us believe in. But unfortunately the real world is dominated by businesses and not by cool software developers. And it just so happens that there are a lot of really badly coded business critical enterprise applications with millions lines of code. Those apps need a major overhaul, not some refactoring.

2 Likes

Confidence in the language is adversely affected when applications which have run happily for years suddenly stop working.

Those other things that you list are nothing but minor gripes by a small number of developers who suffer from OCD. None of those things stop competent developers from writing perfectly adequate applications, so they cannot be classes as showstoppers. What CAN be classed as a showstopper is when a website owner cannot upgrade to a new PHP release because his application won't run.

We are working with Enterprise solutions as well, and we cannot wait until the new version is released due to massive improvements to the internals, both for the speed increases and making it easier to make extensions. This alone should be enough for anyone to update their code base if they are using any of the functionality that is removed.

Those would be welcome improvements, but if I cannot run my existing application under the "new and improved" version of PHP then it makes it nothing more than the "new but unusable" version of PHP.

1 Like

Out of curiosity - would you be okay with it if it had been marked deprecated first?

For example, functionality that has been deprecated is being removed now. Most notably, the mysql_ extension that many tutorials, books and codebases still use. If this were not deprecated but removed outright would it bother you the same as this constructor mess?

The opinion of a few dozen developers is insignificant when compared with the 240 million or so websites whose applications could suddenly stop working because of "necessary" BC breaks.

Something which fixes a serious bug or security issue can be classed as necessary, but if a feature is removed for any other reason - and I put "code cleanliness" and "code purity" in this category - then the BC break will create more problems than it solves.

By breaking BC and passing a huge refactoring exercise onto the user community the core developers are effectively saying that they don't care how much grief they pass on to their customers. No other industry, or indeed other sectors in our own industry, would tolerate such a faux pas in customer relations, so why is it wrong for me to complain about the arrogant, autocratic and dictatorial attitude of the current batch of core developers? I am a customer and I have the right to complain at what I regard as poor service.

It may be the minority is those forums which are regularly patrolled by the paradigm police who instantly jump on any dissenting post, but what about the silent majority who don't read those forums? These are the people who will end up by voting with their feet by not adopting the new release - just like those who cannot move forward from version 5.2 - simply because it breaks their existing applications.

2 Likes

Incorrect. I built my framework in PHP 4 before PHP 5 existed. After releasing it as open source I had to support both PHP 4 and PHP 5 for several years from the same codebase. I actively maintain this framework to this day with a new release virtually every month. I also used my framework to build an enterprise application in 2007 which is used by several organisations in the UK and which is currently being marketed by a US partner to multinational organisations all over the world.

"Maintenance" for me means fixing bugs and adding new features which my customers have requested. I do not have the time to constantly refactor working code with each new release of PHP just because the core developers think that it's "time for a change".

I should point out that since PHP 5 was released the only new feature which I have adopted is the set of date manipulation classes. All those "improvements" to OO I have dismissed as useless window dressing.

You may have a small application and a large pool of developers with time on their hands but others do not. Time can be allocated to fix bugs and deal with changes in requirements as the costs for this time can reasonably be passed on to the customers, but taking time to make the code look pretty is time that cannot be charged to the customers, therefore cannot be justified.

1 Like

There is a big difference between voluntarily migrating to a new language (which I have done 3 times in my long career) and having your existing language changed under your feet without your approval.

I still would have questioned the need for such a change which did not fi any problem but which instead created them.

Are you aware for example that shortly after PHP 5 came out some over-eager core developer decided to remove support for the "var" keyword with the justification that developers should be using "public/private/protected" instead? He was quickly shot down as this was considered to be too much of a BC break for too little benefit to anybody.

Not at all. I changed my framework to allow the use of either the original or the improved extension for MySQL as soon as I had upgraded to MySQL 4.1 and the "improved" extension became available. My code will use the new extension if it has been loaded, but fall back to the old one if it has not. I did not wait until the old extension was marked as deprecated before I made that decision because there were genuine reasons to use the new extension. There are NO such genuine reasons for removing PHP 4 constructors.

What's the problem with the return types feature?
Either
1) return an example type, e.g.,
return 0; //int return ""; string return [];//array , return "True || False"; (recognizing that True or False evalutate to an int 1 or 0) and so on.
2) dual purpose the 'as' keyword and a string representation of the type, e.g.,
return as "int"; return as "string"; return as "bool"; return as "array"; return as "array" "iterator"; OR return as "array iterator"; or as a shorthand to returning a string, return as "";
3) create a "type" keyword just for this.
return type "int"; return type "bool"; return type "string"; return type "array"; OR the specific return type "array" "iterator", and so on...
With strings, a lot can be accomplished, solved. Good Luck.

On return types, it seems a bit remiss to just typehint and return typehint "array". Shouldn't we be have : int[] or : Object[] arrays being type hinted?

If the RFC was to suggest that, you can be sure it wouldn't have passed, and thus we would not have ANY type hints.

There was a separate RFC about collection type hints (parameter type hints; but it would've applied to return ones, had it passed). It seems it's been removed, as I can't find it in the current list of RFCs.

If I remember correctly, the biggest discussion that stood in its way was about NULL as a value. On one side, you have people who believe NULL should not be allowed by this type hint by default, or be in any way doable, while on other you had others who thought (I can imagine for ease of implementation reasons...) believe NULL should be allowed, and some who even proposed it should be so by default when using this type hint. In my personal opinion, those type hints should behave same as today - not allow NULL by default, unless null is specified as a default value.

I don't understand this; do sites just suddenly stop working when a new version is released? Is every version of PHP going to suddenly upgrade to 7 when it comes out? Am I missing something, or aren't there plenty of hosts still running PHP 5.3? Any developer who is using PHP4 constructors has a long time to get that fixed before 5.6 is EOL'd, and if the current method of using them can cause conflicts, I'm not sure what the downside is here besides a principled stand against things changing.

I was not, no, but I am aware of quite a few shenanigans from the internals discussions - it's often been a tragicomic adventure. : )

I believe the argument here is that Tony likes to keep the PHP version up to date, but not the code. In other words, the effort it takes to modernize the code to best practices as recommended by the internals group is not worth it, while the effort of upgrading to a new version of PHP (arguably taking longer), is.

I can sort of relate to this, to each his own after all, but it still seems like resistance for the sake of resistance.

I do completely agree with Tony, however, that a deprecation notice should be implemented first, before removing functionality that can cause BC breaks. It's simple custom and good manners. Let's hope the PHP 5.7 vote re-opens soon, and that the meta-version comes to life for the sake of easier adoption. PHP 7 is shaping up to be absolutely amazing, and it would be a shame if all those stuck on horrid old code were abruptly left behind unable to upgrade versions just because of inertia.