The PHP 7 Revolution: Return Types and Removed Artifacts

Ouch. How long does manual testing take? With unit tests, after a change I can test all code paths with various inputs/outputs in seconds.

How do you do that manually? Load the page in the browser and see if it works? What if it’s a complex page that does something bashed on a large form? Do you fill out the entire form (for each possible error condition) each time? That seems like a very poor way of working both in terms of time spent and the quality of the testing.

I’d highly recommend giving TDD a try as it will improve both your code and your efficiency as a developer.

1 Like

Wow. If Tony had his way we’d never have seen php 5. The jump from 4 to 5 was no picnic either, especially if you relied on register_globals.

Old php 4 constructors are NOT GOING AWAY. They are being DEPRECATED. That’s a HUGE difference.

Tony, you claim to be “OLD SCHOOL”. If you are OLD SCHOOL you’d know that php 4 constructors aren’t going away any time soon. How long has mysql_* been deprecated? 8 - 10 years? How long did it take that major security hole “register globals” to be removed… 5-8 years?

PHP 4 is dead. That’s just the way it is. Time to catch up with the rest of us or find yourself unemployable. It’s your choice.

I for one am very happy with the direction php 7 is going. I can’t wait to install this on my machines.

The original RFC called for PHP 4 constructors to be REMOVED, not DEPRECATED as the author had already assumed that they had been deprecated.

Incorrect. I am in favour of improving the language, but not if it breaks BC for trivial reasons. The removal of register_globals was for a legitimate security issue, and it did not affect me as I had already changed my code after reading about the problem.

I no longer use PHP 4 on any of my development machines as everything runs quite happily with PHP 5. What runs now with PHP 5 I expect to run with PHP 7 without having to make any amendments.

You have not factored in the time that it takes to create all those unit tests. You also fail to realise that automated unit testing and TDD only became fashionable quite recently (within the last five years). I created my framework and my main application much earlier than that, which means that it was done without any automated unit tests, and I do not have the time (or the inclination) to learn about all the new testing tools and create retrospective tests.

I am paid to be a designer/developer, not a tester, so I cannot justify doing what I am not paid to do. The QA department is responsible for testing and that department has its own budget, its own staff and its own set of tools.

That’s how it’s been done for years, and it is quicker for me to do it this way than the “new” way.

You also fail to realise that my framework contains a huge amount of reusable code, so that when I test a new script I don’t have to test everything, just the places where I have added custom code.

It is only your opinion that it will improve my code and efficiency as a developer. I strongly disagree. It will not improve my code if I have to take an existing production component and refactor it just because the unit testing framework is unable to work with it as it is. It will not improve my efficiency as a developer if I have to spend half my time in non-development work, and writing unit tests is separate from actual development. Instead of spending 8 hours each day on development you are advocating that I spend 4 hours on development and 4 hours on testing. That means that 8 hours of development will now take me two days instead of one. How is this “more efficient”?


First let me start by apologizing for my harsh comment. I should have slept on it before commenting. With that said, the overall point still stands.

Well then I stand corrected on this one point. Still I can’t say I disagree with the move, php 4 constructors have been considered bad practice since php 5 was released.

You’re previous posts talk about being in enterprise, which I am as well. I get that enterprise code tends to stay in production till the “end of time.” With that said, enterprise companies also won’t be upgrading to PHP 7 for some time to come.

The fact that some people consider them to be bad practice is irrelevant. What about those who don’t? Why should the opinions of the few be enforced on the many?

It would be a shame if they could not take advantage of the speed improvements and bug fixes in PHP 7 without having to refactor their entire codebase. If the core developers cannot improve PHP without breaking BC then they have only themselves to blame if the adoption rate for PHP is slow. Remember how long it took for PHP 4 sites to upgrade to PHP 5, then look at how many sites are still running 5.2 because of the amount of work required to upgrade to 5.3 and beyond. Other suppliers who treated their customers which such contempt would not last long in the commercial world, so why should we have to deal with it in the open source world?


What are you talking about? The PHP devs have ALWAYS tried to make sure that the next version is easy to update to. I know I’ve pointed this out earlier but how long did it take register_globals and mysql to be official removed from the language. Well… register_globals was over a decade? Last I heard Mysql will still be available, it’s just being moved to PECL, so even this old driver will still be with us for some time to come.

From my perspective I would argue that the devs have always been too worries about BC breaks and many a good RFC has been denied because of it. The language has to evolve and stay with the times or it will find itself obsolete. Much like developers who get complacent and don’t keep up with times.

Really? Show me a vendor that’s been around as long as PHP that hasn’t had BC breaks. Does your old Dos game work in windows XP? Can your PowerPC upgrade to the latest OS X? Do your printer drivers from XP work in Vista? Does my old CGA/EGA graphics card still work in today’s PCI slots? How about VB? Does my old VB script still work in Java 6 to java 7?

It seems to me that PHP is one of the very few products/languages that is still being actively developed where code I’ve written over a decade ago still works almost completely out of the box.

Now I won’t say that the current development process is perfect. For people like us in the enterprise world a 1-2 year maintenance plan per release is a bit too short lived. What I’d like to see down the road is an LTS type of version. One that we can count on for support for while. With that said, I’m happier that development in PHP is now moving forward, so I can live with the occasional BC breaks every 1-2 years.


Although change / refactoring may be needed for our code bases when or if we decide to upgrade to 7, some are looking at changes being a bad thing.

Many ( but not all ) experienced developers understand that for a large application to survive a long time, that regular refactoring is required.

The world has such fluid changes; even for php. New APIs, extensions and frameworks, that for new and intermediate developers, as soon as this is understood, applications can be more resilient to change.

Yes moving to php 7 will likely drive the need to refactor. This is an opportunity to refactor code, make the move to 7 and improve code.

okay, but it does seem to me that only the absolute minority would question the validity of DI, the majority of competent programmers embrace it with passion.

On a side note, I thought you already had an account here on Sitepoint, what happened to it?

And I find your comments in this thread very interesting too, apparently you have been a ‘good friend’ with TomB and many sitepoint gurus a long time ago:

So you are saying that because I don’t use DI that I am not a competent programmer? That is an arrogant assumption as well as a personal insult.

I don’t use DI for the simple reason that I do not have the problem for which DI is the solution. I do not have to regularly swap the dependencies in my entire application, so putting in code to make it easier to do what I am never going to do would be a complete waste of time.

I tried to use that, but it wouldn’t work for some reason. I thought that it may have expired because I had not used it for a long time, so I created a new account.

While there are some core devs who try to stick to that principle and try to improve the language in an evolutionary way, there is a vociferous group out there who want to change the language in a revolutionary way. They want to replace weak typing with strong typing, they want all PHP functions to be renamed to suit “their” conventions, they want PHP to be a “purer” OO language. If you read my article at (which sparked this debate in the first place) you would have a better idea of my personal standpoint.

[quote=“Westin_Shafer, post:189, topic:110202”]
From my perspective I would argue that the devs have always been too worried about BC breaks and many a good RFC has been denied because of it.[/quote]
I am not against new features being added to the language provided that they are optional and not mandatory. What I do object to is when a new feature replaces an old feature so that perfectly valid code which worked in all previous versions will no longer work in the new version.

[quote=“Westin_Shafer, post:189, topic:110202”]
The language has to evolve and stay with the times or it will find itself obsolete. [/quote]
There is a difference between change by evolution and change by revolution. I am willing to support the former but not the latter.

If I have a large application with code that works, why should I have to refactor it to use a new method which produces exactly the same result but in a different manner? In the commercial world such tinkering without a measurable benefit would not be justified.

I also have code which I wrote over 10 years ago which still runs in the latest version, but such longevity will be nothing but a dream if the revolutionaries have their way and introduce unnecessary BC breaks simply because they can.

It depends on whether the change is evolutionary or revolutionary. Adding a new feature to the language without affecting any existing feature is evolutionary as existing code will still work. Replacing old syntax with new syntax is revolutionary as all applications using the old syntax will have to be refactored before they will work in the new version.

Define “regular”. I deal in large enterprise applications which have over 2,000 user transactions, and once I have written code that works I don’t expect to revisit that code unless I am fixing a bug or dealing with a change in user requirements. There is no budget for regular refactoring, only for dealing with customer’s requests.

Oh my, you are so easily offended. Well, if you interpret my words, theres a difference between ‘majority of competent programmers embrace it with passion’, and ‘all/only competent programmers embrace it with passion’, right? I was not making any assumptions, I just state what I see as fact, and my wording has been extra careful.

In fact I know you too little to even say what kind of programmer you are, and I am honestly not interested in knowing this anyway. But I guess, your reply did answer an important question we have all been wondering about: Why you have been arguing so intensely and aggressively in this thread - 'cause you feel every counter-argument are arrogant and insulting. I dont feel its me against the world when people dont agree with me though, its kinda strange.

Just curious, but what exactly is it that you put into “2,000 user transactions”? Are we talking logged in accounts at any time, traffic per second, database transactions per second or am I perhaps completely off?

1 Like

To be fair, I work on an app that gets about 50-70 page views per second and some of the pieces haven’t been refractored since the 90’s. Some of it is even built in a proprietary language that pre-dates PHP.

Too little time. Too few people. Too much code. And it still works fine. Amazon notoriously worked in a similar way for years, but ended up biting the bullet and just getting it done. The whole idea of “constant refractoring” is a good idea in theory, but realistically pretty it’s silly.

A “user transaction” can also be known as a “unit of work”. It is an option on a menu which the user can select to do something useful, such as “Create Sales Order”, “Approve Sales Order” et cetera. It has nothing to do with the number of users who are logged in at any one time, but it is a count of the number of things a user can do once he/she is logged in.

I defend myself aggressively whenever I am attacked aggressively. It is not a case of someone saying “I see that you are doing so-and-so, but personally I prefer something-else” but “You are not doing the same as all the programmers I know therefore you are not following best practices, you don’t understand what you’re doing, you are not a competent programmer and all your code is crap”

I have never said that my methods are the best methods, or that everybody should do what I do, just that I choose to do something different, and I am constantly being attacked simply because my methods ARE different. Too many programmers are taught only one way to achieve things, so they automatically assume that what they are taught is the ONLY way, the ONE TRUE WAY, and that anyone who deviates from the designated path is a deviant and a heretic.

Although you’ve drawn a line re evolutionary and revolutionary, I know that in every long-term language still going through growth that sometimes changing existing features is required. We are not sure why the choices were made, but generally this is not an oversight but a carefully considered choice. These changes are made because of security concerns, memory stack problems that won’t refactor well…

Generally refactoring is only required when code can be optimized, extracted into several methods or new classes. Any code that is highly coupled tend also to be targets; especially when major changes can cause unwanted major changes.

If your code works it is harder to argue that it would benefit it, without seeing it. The few examples of your pastebin work could use refactoring.

My only point, is if your public api of your code is under good unit test coverage, then refactoring to ensure your public interfaces behave the same with php 7 changes, it wouldn’t be an issue to change.

edit nvm.

Words are being misused causing confusion. Not getting into the middle of it. I think I’m just going to stop clicking this thread.

For future reference, you’re looking for the term is “possible user actions”.