The PHP 7 Revolution: Return Types and Removed Artifacts

With the planned date for PHP 7’s release rapidly approaching, the internals group is hard at work trying to fix our beloved language as much as possible by both removing artifacts and adding some long desired features. There are many RFCs we could study and discuss, but in this post, I’d like to focus on three that grabbed my attention.

PHP 5.7 vs PHP 7

As I mentioned in the last newsletter, 5.7 has been downvoted in favor of moving directly to PHP 7. This means there will be no new version between 5.6 and 7 – even if the new version was only to serve as a warning light to those still stuck on outdated code. Originally, 5.7 was not supposed to have new features, but was supposed to throw out notices and warnings of deprecation about code that’s about to change in v7.

It would also warn about some keywords that are to be reserved in PHP 7, so that people can bring their code up to speed with a sort of “automatic” compatibility checker in the form of an entire PHP version. The thing is, however, as I argue in the newsletter, that most people technologically competent enough to follow PHP in its upgrade path by keeping up with the most recent version aren’t generally the type of people to actually be using code that might break in PHP 7.

Note that while the voting is over, that doesn’t prevent it from being resurrected at a later point in time. The “nay” voters in the first round seem to have argued against 5.7 due to the lack of significant changes, but with recent changes and new votes on other RFCs, that may well be reconsidered. Let’s see what happens.

Return Types

With a vast majority voting “yes”, PHP is finally getting return types. The results of the vote are still fresh, but definite. Starting with PHP 7, we’ll finally be able to indicate proper return types on functions in the form of:

function foo(): array {
    return [];

An improvement? Definitely! But perfect? Unfortunately, no:

  • the return types can only be what we have for types right now, meaning no scalar values, no return types like string, int, bool, etc. This means that your methods and functions that return such values will still be unsigned. You can remedy this by returning instances of wrappers for such values, but that’s overkill in the vast majority of cases.
  • no multiple return types. If your function returns either an array, or an Iterator object, there’s no way to indicate that via, for example, array|Iterator as we do in docblocks.

Some people also complained about the type declaration being after the closing parenthesis of the argument list, rather than before the function name, but to me, this is nitpicking. Popular languages such as modern C++ use the “after” syntax, and like the RFC states, this preserves the possibility of searching for “function foo” without any necessary regex modifications. What’s more, this is in line with what HHVM uses, so it’s an added unintended compatibility bonus.

Others complained about the “strictification” of PHP, but as one commenter states, you really find the value of this when you start coding against interfaces or inheriting other people’s code. Besides, as long as it’s optional and its existence does not in any way affect PHP’s general performance or stability, there’s no harm in it. Complaining about it is, to me, akin to complaining about OOP being added to PHP when procedural spaghetti worked so well for most cases back then. Languages evolve, and this is a step in the right direction.

What do you think?

Removing Artifacts

The upcoming version proposes to remove PHP4 style constructors (yet to be voted on). You can read what this means in the RFC, it’s simple and would be futile to repeat it here – but what’s actually very interesting is the mental anguish such a move seems to be causing some people. For example, this. “Please do not break our language”, pleads Tony, who seems intent on using its broken features.

The post is well written despite the obvious anger, but it makes me wonder – if you’ve kept such a codebase alive for so long, is there really a need to upgrade to PHP 7? And if there is a need to upgrade to PHP 7, is it not easier to simply hunt down the offending classes and fix their constructors? Surely this is something you can delegate to juniors, given enough unit tests in your code base to make sure it all goes well? And if you don’t have unit tests, if your app is a mess, do you really hope to benefit in any way from moving to PHP 7? Wouldn’t you be better off Modernizing your Application first?

The sentence “This means that code which I wrote 10 years ago should still run today, and should still run 10 years from now.” is, to me, madness – you definitely and absolutely should not expect this of ANY language across major versions. To draw a parallel from the real world, you shouldn’t expect to be allowed to own slaves today just because a law from long ago said you could. Yes, the BC break came after a bloody revolution, but when most slaveowners repented or died, there was peace.

Granted, Tony is right in that it would take effort to remove the feature, while it would take none to leave it in. But in the long run, it will take more collective effort to fix the problems these constructors sometimes cause, than to remove it right now.

Understandably, BC breaks always upset some people, even if major versions are perfectly okay having BC breaks for the purpose of progress. But imagine the fervor when such people find out about this. Heck, imagine what would have happened if WordPress hadn’t stepped into 2001 last year and updated to mysqli instead of mysql – either no WP installation would work on PHP 7, or PHP 7 would keep an unsafe and long deprecated feature for the sole reason of keeping WP users happy.

My advice to those fearing PHP 7 is – stop. If you don’t want to upgrade, don’t. If you could be on 5.3 or 5.2 for so long (looking at you, CodeIgniter), you can be on 5.6 for another decade – but let us have modern PHP. Leave progress up to those who are willing to accept it.

What say you? Is this removal of artifacts nonsense or needed?

Aside: Extension API Changes

As an interesting sidenote, there are some changes in PHP 7 that might actually cause a bit of a delay with extension porting to version 7. The API for building PHP extensions is still under a revamping (read: cleaning) process and all is subject to change – nonetheless, this provocative tweet from Sara Golemon gathered quite a bit of attention.

She basically says the changes in extension development from 5.6 to 7 will be so great, you might as well learn how to make HHVM extensions. She then proceeded to craft a lengthy series on that exact topic, explaining in depth and on examples how to create an HHVM extension.

Do you develop extensions? Did you study the changes, or do you feel like it’s still too early to tell if they’ll have an effect?

Edit: It has been brought to my attention that Sara has later started documenting a new extension API compatible with both HHVM and PHP 7. We could – it seems – have extensions compatible with both runtimes!


As usual, there’s no shortage of drama in PHP land. Like all major revolutions throughout history, the PHP 7 revolution will also be spilling some blood before producing something awesome. PHP 7 is still a long way off, so even if you’re caught in the crossfire of musket shots, there’s ample time to get to cover. Unless you’ve been sleeping under tank tracks, then there’s little either side can do to help you.

What do you think of these RFCs? How do you feel about PHP 7 in general? Is it heading in the direction you’d like it to head in? Let us know – we want to hear your thoughts!


I think we in "PHP Land" can be really happy Facebook came up with HHVM. It seems to me the PHP devs have gotten a wake up call and a more positive outlook for PHP can be seen for everyone. It isn't perfect, but what is perfect in life? As for the exact changes in PHP7, I'll wait until the first betas roll out to start to have an opinion on them.

As for Uncle Tony's rant. Check out his request for support on LinkedIn's PHP Group. He basically got stomped on by everyone who answered, including me. One of posters noted the best argument about removing PHP4 style constructors. He said...

Q: Again, two choices: both have identical results except one has a slight chance of failure and the other does not. Which do you choose?

A: Depends:
* Uncle Tony: The option with the slight chance of failure.
* Everyone else in the entire universe who has lived, is living, or will live: The option with no chance of failure.

The discussion is entertaining, if nothing else. smile



Sounds like Python 3...


Indeed! Missed that, thanks! :smile:

That is a common concern, yes, but we have the advantage in:
1. that the changes won't be that great and will remove only obsolete functionality which has no room in a modern language any more, allowing all modern packages, libraries, CMSes and frameworks to function as usual
2. the community is much greater and far more involved with the lower level stuff in PHP (many are at least dissecting frameworks, if not building their own) so the manpower to convert those few packages that people actually use but which still won't be able to digest PHP7 is more than present.

The only problem might be extensions, but even that will be largely taken care of by both the community and those extension developers whose extensions are still being actively used (most of them still keep an eye on them and keep them up to date).

I don't think we have anything to worry about. With good repositories such as adopting PHP7 from day 0 and pushing out good resources about adoption and using the new version properly, I don't think we'll have much to fear. It's just a matter of reaching those who are still in the dark, and that's something everyone is already trying to do.


One change I'd like to see in PHP 7 is the old mysql_* extension removed, imo people and companies have had more then enough time to have migrated away from it to either the mysqli_* extension or PDO. If they've not finished then they should really be 80-90% migrated


The vote just came through today. It is getting removed.


I believe they've just voted to unbundle the mysql extension from PHP in version 7. Although that doesn't stop hosting companies from choosing to manually install it, which I'm sure some will.


I think a lot of people (those people, who have an interest in saving money on servers) will be eager to take up PHP7, because of the large performance boost and RAM savings it will supposedly have. I also really hope, a form of JIT compiler will also come not all too long after PHP7's release.



And of course now that the mysql_ functions are no longer defined in the core, the door is wide open for people to write their own mysql_ functions to wrap the mysqli_ ones just so they don't have handle rewriting their code to use mysqli_.
I'm not saying I endorse it (I don't), and I'm not saying it's pretty (it isn't), but you bet it will happen, simply because it's (probably) the fastest solution to work around the removal of the mysql_ functions.


My first thought was "Oh they're pulling a Java. It's 5.7, but 'PHP 7' sounds better".

I support the removing of the mysql_ extension, but i'm not sure I see the doom of it that Scallio points out - after all, what is PDO if not a wrapper around mysqli_ functions, if you only use it on mysql databases?


I don't get it. Why on earth don't the very smart dev people around PHP simply write "official" upgrade wrappers for each release, let alone for something like 5.6 to 7.0?

As a real world example I've used MySQLConverterTool from Github on 2 medium sized projects and didn't have to tweak the end results, it "just worked", and I couldn't help thinking "my goodness, why don't smart people write more of these converters?" so the rest of us have a better chance of staying uptodate with our projects.


I do not like PHP 7's return type hinting syntax, Id rather have the function keyword replaced by the return type, like what you do in C++, Java and C#. The function keyword bothers me, especially used in conjunction with return type. Its a lot of typing, plainly ugly, and very inconvenient to use. Just compare these two:

public function getIterator(): Iterator //bad, ugly, but was chosen as the syntax...
public Iterator getIterator(); //good, elegant, but was not chosen as syntax...

It seems that the PHP internals are unwilling to make the function keyword disappear, not even optional at this stage. I hope return type hinting will be optional then, I aint likely to use this feature unless the syntax changes dramatically.

Just like PHP's namespace syntax, I am fine with most of it, but cannot withstand the leading backslash(like \Exception, \PDO, etc...). For this reason I always import all namespaces, and never use the fully qualified names without importing, except when dynamically loading/instantiating objects of variable classes. sigh


It'll be optional. There have been many discussions about the type before or after the function name, and this was chosen in respect to C++ and general habits PHP devs have built over time. Perhaps in the future, but I'm not at all bothered by this in the age of live templates. I just type "pfa " in PhpStorm and get

public function functionName(): array {


The namespace syntax has been debated to no end, and this was the best solution at the time. What would you like to have instead? What bothers you about the backslash that much?


Well it can be after the function name, this is lesser of an issue to me. I just do not want to see the function keyword used in conjunction with return type hinting. To me its one way or another, either function keyword without return type, or return type without function keyword. If both exist in a method declaration, it looks extremely ugly and painful to the eye. Also a lot more typing and inconvenient to use.

For the namespace, I think you misunderstood me here. The backslash is not something I'd prefer, but its not really a big issue. What annoys me tremendously is the leading backslash, or more precisely, PHP's namespace resolution rules. For instance, I am okay with Symfony\Bundle\FrameworkBundle\FrameworkBundle(), but \Symfony\Bundle\FrameworkBundle\FrameworkBundle() disturbs me. Do you see exactly what I mean now? The leading backslash is ugly and error-prone, I already lose track of how many times I've seen myself and colleagues getting syntax errors due to missing this leading backslash for Exception, ArrayObject and PDO classes. Seriously, have you seen another programming language that uses this ridiculous namespace resolution? We do not see things like .java.collection.arraylist, or .System.Data.Entity, right? So why do you have to use a leading backslash in PHP when referring to a class outside of the current namespace? Isnt this a language design flaw?


I agree with that, I'd rather all namespaces were resolved from root by default, rather than trying to be relative when the leading backslash is missing.


Yeah, I have no idea why PHP's namespace does not resolve from the root by default, rather at the current namespace. The leading backslash annoys me so much, I always import all classes I so I do not have to use it. sigh I hope in PHP 7 this will be fixed, but well it may lead to backward incompatibility.


As you have seen fit to criticise my article then you must surely allow me to reply. BTW, the name is Tony with a "y", not Toni with an "i". "Toni" is a girl's name, and while there are many who think that I am a big girl's blouse (or even worse) spelling my name right would be much appreciated.

Note that although my article concentrates on the RFC for the removal of PHP 4 style constructors it also mentions another RFC on scalar type hints. It is the principle of the core developers breaking the language for no good reason that I (and a huge number of others) object to. Removing existing functionality in order to fix a bug or a security issue is a good reason, but removing something simply because you don't like it is NOT a good enough reason.

“Please do not break our language”, pleads Toni, who seems intent on using its broken features.

How are PHP constructors "broken"? What are the problems they cause? They have been in the language for 15 years and coexisted with PHP 5 constructors for over 10, and I have been using them with every PHP release up to and including 5.6.4 without an issue.

Please also note that PHP 4 style constructors have NEVER been marked as deprecated in the manual (check for yourself) nor by the compiler, so they cannot be suddenly removed in the next release.

if you’ve kept such a codebase alive for so long, is there really a need to upgrade to PHP 7?

The need to keep abreast with the latest PHP release is highlighted in article All those 240 million website owners out their would LOVE to keep their versions of PHP up-to-date so that they can benefit from all the bug fixes, but they can't upgrade if it breaks their applications.

It was the volume of BC breaks which caused the slow adoption of PHP 5, and if PHP 7 continues down the path of even more unnecessary BC breaks then it's adoption rate is liable to be even worse.

If PHP 7 cannot be used to run existing applications which run happily under PHP 5 then it does not deserve to have "PHP" in its name as it will effectively be a different language and not the same language with improvements.

The sentence “This means that code which I wrote 10 years ago should still run today, and should still run 10 years from now.” is, to me, madness – you definitely and absolutely should not expect this of ANY language across major versions.

I disagree. I have been designing and building enterprise applications for over 35 years using languages such as COBOL (16 years) and UNIFACE (10 years). In all that time both languages went through major upgrades without any BC breaks whatsoever. While new features were added the language developers took great pains to maintain all the existing features. This is because the developers who maintained the language were competent professionals who put the needs of their user community before their own personal preferences.

There are some people who say that PHP will never be anything more than a "toy" language as it will never be good enough in which to develop enterprise applications. I know for a fact that the language IS good enough as I do nothing but develop enterprise applications, but the only stumbling block is this continuous flow of unnecessary BC breaks.

Enterprise applications deal with enterprise data and not only does enterprise data have a long shelf life it is expected that the applications themselves should have a long shelf life. Developers of enterprise applications therefore expect two things from their language - stability and longevity. If PHP cannot provide these then PHP will never become an enterprise language.

I have been told by many critics that I should grow up and do what the core developers tell me to. Instead my message to the core developers is quite simple - if you want PHP to be treated as more than a language for writing toy websites then it is YOU who need to grow up. If you want PHP to be a "big boy" language then it is about time you adopted "big boy" practices and started to treat your user base with compassion instead of contempt. You can start by NOT breaking the language without VERY good reasons.


Thank you for the response, I'm glad to have you chiming in here!

The problems have been named in the internals list, and have been, in part, mentioned in your article. Some breakage here and there and unexpected behavior. Nothing critical from my point of view, but it happens nonetheless.

I completely agree with you on this one. Functionality that is to be removed, especially if considered to have a large enough user base still, should first be marked as deprecated. But who is to judge how large of a user base is still using a given functionality?

And what is the status of these languages today? How used are they? How many courses do you see on them? How many newbie developers ask "Should COBOL be my first language?" rather than inquiring about PHP?

On a final note - I'd like to inquire: does fixing your codebase to respect the new constructor rules really entail so much effort? Surely if you search for all instances of such behavior and have a sufficient amount of unit tests in place you could fix all of it in a day or two? I really am curious as to the nature of your application that is so brittle such a change would destroy it, and yet still incompatible with minor code alterations as to avoid this disaster.


The problems have been named in the internals list, and have been, in part, mentioned in your article.

The so-called problem with traits and namespaces is that they completely ignored PHP 4 constructors in the first place, which is the fault of the developers who implemented those changes.

The problem of "accidentally" creating a method with the same name as the class and thereby "accidentally" creating an unwanted constructor is purely the developers fault. Those of us who have been around long enough to know what we're doing would not make such a newbie mistake. This is a developer error, not a language error.

The problem with a subclass not knowing the name of the parent constructor, of if even one exists, will be solved by if it were extended to deal with both styles of currently valid constructor.

I completely agree with you on this one. Functionality that is to be removed, especially if considered to have a large enough user base still, should first be marked as deprecated. But who is to judge how large of a user base is still using a given functionality?

There are over 240 million websites out there running PHP. Unless you are prepared to run an audit on every one you cannot say for certain that any piece of functionality is not being used. It has already been stated that significant portions of the PEAR library still use PHP 4 constructors, and there must still be a significant number of applications out there which were developed using PHP 4. If the PHP 4 constructors have never been marked as deprecated then their developers had absolutely no idea, no warning that their code needed changing.

There is a rule that nothing can be removed from the language without it being marked as deprecated first, and PHP 4 constructors have never been marked as deprecated. As the next major release as 5.6 will be 7 (the need for 5.7 was voted down) it will therefore not be possible to remove them in 7.

And what is the status of these languages today?

You don't understand the difference between deliberately moving to a new language and updating the existing language. My company moved from COBOL to UNIFACE because the market for new COBOL applications for the HP3000 dried up. UNIFACE provided the ability to develop applications which could run on a variety of platforms with shorter development times. The original version was for the desktop only but a later version also provided the ability to access applications via a web interface. Despite the numerous upgrades to the language there were never any BC breaks whatever ran in the current version would always run in the new version.

I decided that web applications were the way of the future, and that UNIFACES's ability to develop web applications was too clunky for my taste. As the language could never be modified to meet my expectations I decided to switch to a language that was designed specifically for the web, not one with a web add-on. That is when I discovered PHP, and after proving to myself that it could do what I wanted I stuck with it, and I am still with it after 14 years.

Updates to a language, such as new features and bug fixes, are perfectly OK, but BC breaks are not. It is one thing to move to a new language because the old one doesn't do what you want, but it is another thing entirely to change the language into something else and completely destroy the old language. Any new version of PHP which is incapable of running EVERY existing application that runs under the latest version of PHP 5 does not deserve to use the name "PHP" as it will effectively be a new language instead of the old language with new features.

On a final note - I'd like to inquire: does fixing your codebase to respect the new constructor rules really entail so much effort?

It's not the effort, it is the principle. The idea that the core developers can remove long-standing functionality from the language FOR NO GOOD REASON and thereby break existing applications is wrong. It destroys confidence in the language. The core developers should learn to be more considerate to the millions of developers who use the language and less selfish in trying to force their personal preferences on the entire community.


Ammended, Tony's name has apparently been updated. I am still not happy about the attacking nature of this article, or how rude the OP is, but cannot find a complaints button, which is very telling of sitepoint; I only signed to comment because I thought the article was so bad, so untechnically focused and so rude.

I Do share the idea, why would we tell the PHP core devs what to do, but Tony has made some great points, I do agree with in principle, and after the latest post (see below) it seems the article author agrees in principle too...

As the writer does say, it's done now, and if for no reason other than this, I hope PHP7 crashes, and burns just like Python 2 did. It talks in places about compatibility with HHVM, as if that were some goal of PHP. In reality PHP should not be a web-application, it should form a part of it, and let more mature, more performant back-end compiled langs do the heavy lifting. After all, I never saw LUA trying to implement PDF utilities, or zip utilities, it simply hooks other frameworks like a lot of high-level utility langs do...


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: 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.


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.


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.


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.


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.


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.


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?
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.


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.


There are two degrees of "hurt" when you break BC.

The first is if you do any BC breaks at all you need to involve a developer to do an upgrade. That's problematic for existing deployed software, because there might not actually be a developer around. At that point, it may make more sense to switch to a different platform / solution entirely. Any BC break in PHP therefore leads to users abandoning the platform. Meanwhile, you don't gain any new users, because supporting less syntax never wins someone over. Only if you break BC to introduce new and amazingly improved syntax do you gain users. Breaking BC loses you users but doesn't win you new ones to replace them. Maybe those lost users are the kind you don't want, but still, it happens and it is a choice platform owners must make deliberately. For me this would be a reason to never drop support for old syntax unless it is needed to introduce new syntax. I would have kept the old constructor syntax in.

The second is death by a thousand paper cuts. Every BC break adds cognitive load to the developer supporting their software. Each time you need to change, and retest. Real world software does not have perfect unit test coverage, so costly manual testing is necessary each time, which you shouldn't force your users into unless it's really necessary. That's why when you need to break BC, you should do it all at once, so for me PHP 7 is a good time to do it. However, that does not mean that breaking BC in every PHP release is a good idea. PHP's strength is BC support. Let's not lose that.

Finally, let me mention that if PHP had LTS releases this issue would be much less critical. If say PHP 5.6 was supported for 10 years after its initial release (similar to what Microsoft would do with their server products), then people could migrate those codebases as part of the natural upgrade cycle that befalls all software. Again this is a choice you make as a platform. Drop support quickly, and you bleed users but have the agility to win new ones through building a better platform. Drop support slowly and you have a larger user community, but platform improvement must happen orthogonal to existing syntax.

All I would ask for is for choices around BC to be made deliberately and with due consideration to the difficulty of finding resources to adapt a codebase to changes in the underlying platform when the business owners want us developers to be building all features all the time.


Yes, If they try to upgrade to the new release.

No, because their applications will more that likely stop working because of a BC break.

They are still running older versions of PHP simply because their customers' applications won't run on the latest release due to all those BC breaks.

PHP 4 constructors are still fully supported in PHP simply because they have NEVER been marked as deprecated, so to say that they are obsolete and should not be used is just plain WRONG!

The only "conflict" that has been reported is where a newbie programmer creates a class method with the same name as the class, and without a separate __construct() method, without realising that it automatically becomes the constructor instead of a separate callable method. Such newbie developers should RTFM (Read The Friggin' Manual).

The downside is all the unnecessary refactoring that developers have to go through in order to upgrade to a new release because of a frivolous BC break. I use the term "frivolous" because it is not to solve a genuine bug or security issue.


There simply needs to be an ini switch which enables php4 constructors and all these issues are solved. It's off by default and people with legacy code can enable it. Newbies don't get confused, the manual can be simplified and anyone who really needs this behaviour can enable it.

I agree that breaking BC for everyone is not really a viable solution. It causes problems because someone can't simply upgrade PHP on a site without investing time redeveloping parts. Clearly that's not good from a business perspective. The result of this is that old PHP versions stay on servers running old sites, which then become security issues because updates are no longer issued for those versions.

Breaking BC for everyone is a bad move but so is keeping BC for everyone.

FWIW: It would take about 10 minutes to write a script that updated all PHP4 constructors in .php files to use the PHP5 __construct()


Then take a look at which show that this faux pas was fixed in version 5.1.3

Correct. I want to ensure that I am up-to-date with all bug fixes, but I do not see why I should be forced to refactor my code for an unnecessary and frivolous break in BC. If it is a choice between a single core developer doing an hour's work and 240 million website owners doing an hour's work each then which would you describe as being the most cost effective?

Wrong. I am complaining about being forced to do some unnecessary refactoring because of a frivolous break in BC.

Your use of the word "horrid old code" is entirely subjective and unnecessary. Code does not have to be "pretty", it has to be "effective". Ugly code which works is far better than pretty code which does not. I do not like having to refactor my code just because some junior programmer has taken it upon himself to redefine what "pretty" means.


Why is keeping BC for everyone bad?

That's still more effort than would be required to leave them in.


I am grateful that you have taken it upon yourself to engage in this topic. I know how much effort it takes to argue against such a tide, and standing your ground so firmly is admirable at the very least. I also appreciate and understand that you may have code you don't feel like refactoring, and I completely agree that a feature should be marked deprecated before being removed. But I assure you, and I say this with the utmost sincerity, that I am junior to you only in age. That is not to say I may outdo you in this or that kind of task, but that I have seen and dealt with enough code, both legacy and up to date, to be able to objectively conclude which code is and is not pretty. One might argue that beauty is relative, and prettiness of code in peers of the similar level of experience may very well be, but generally, a senior will likely be able to recognize pretty (and, by extension, ugly) code sooner than a junior.

Just as we once considered crinoline supported dresses to be what gives women the default of beauty and elegance, and doctors recommended cigarettes as a good solution to that nasty cough, so too can code standards change and we can alter opinions on what good, healthy and pretty code should look like. Not based on feeling or a mere whim, but based on research and countless experiences in the field.

I would argue, therefore, that code that has the potential to confuse, even the least bit, is uglier than code which is effective.


You must not have any experience with .NET then smile

Major versions (based on any version pattern your read) typically do not guarantee backwards compatibility. PHP has been permitting this for so long, it is likely leading to code staleness, redundancy, additional tests, and many hidden problems as they implement the same feature in different ways. It isn't good for the language as a whole for those reasons, let alone the support time it takes to properly ensure each way a feature can be implemented is working properly.

Don't get me wrong. I've enjoyed PHP since I started using it when it was in the stage of going from PHP 3 to PHP 4, but I'm completely shocked they really haven't introduced breaking changes across their major versions (to the extent .NET has).

.NET 1.1 had many breaking changes when going to 2.0, then it had a few more going to 3.5 and 4.0 introduced even more. All of the changes actually have been better for the language. It standardized a lot of the internal classes of the framework and it speed up the CLR by allowing it to do less processing.

Their support time increased and their development time for patches also saw improvements since they didn't have to support the initial implementations that existed way back in 1.1. As a whole the language was in better position to tackle "how can we help our developers use this language going forward" versus "how do we ensure we don't break X which still exists from 2-3 versions ago".

As a developer, I write a lot of APIs (that is probably 80% of the work I do on a regular basis). If I had to support v1 of the API and keep it running through v4, I'd go crazy. The amount of bloat that would add, the strain it would be on our QA department, and the little benefit it would really have for our users isn't worth it. There are reasons why changes were made, to provide a better overall experience/performance boost.

You may see it as unnecessary changes, but really it is a gateway for you to radically improve your codebase and reconsider some of the legacy aspects of your product. What you did back then, might not be the best approach, best performing way today (I know code I wrote in PHP 4 definitely wasn't the best approach to what exists today).


So you're expecting developers will upgrade to PHP7 and leave their code exactly as-is? But we shouldn't fix this conflict b/c it caters to newbie developers?

I mean, PHP7 is a major release; while I don't know for sure, I'm extremely doubtful the only change you'll have to make to your code to make it work with PHP7 is changing your constructors. If this is one of several BC-breaking improvements to PHP, I really don't see why this is an issue.


My code can only be "improved" by fixing bugs and responding to changes in my user requirements. Taking time out to rewrite a piece of so that it does just what it did before, but differently, is time that I cannot afford to waste.


My code can only be "improved" by fixing bugs and responding to changes in my user requirements. Taking time out to rewrite a piece of so that it does just what it did before, but differently, is time that I cannot afford to waste.

Clearly that is not the case. You've spent more time arguing here and elsewhere than it ever would have taken to change the code.


That's unfortunate and likely not a good strategy moving forward. At some point every application gets a rewrite. I've been a part of that many times, it was a necessary thing for us to do (as a company) to stay relevant in an ever changing environment/market.


Yes, and so are they. The only reason they don't upgrade as quickly as they could do is because of unnecessary and frivolous BC breaks. If you look at you will see the following for PHP usage:
- 19.5% of sites are still on version 5.2
- 45.5% of sites are still on version 5.3

That means that 65% of PHP users are at least 3 releases behind. Is this an issue or not? And what causing this situation? Why, breaks in BC of course.


Why, breaks in BC of course.

I'm interested to know how you arrived at this claim. There's numerous reasons people may not upgrade: 1) they may not see the need. They got their wordpress site working there's no reason to ever touch it again. 2) Their OS may not provide an update to the latest version. I believe CentOS 6 only provides 5.3 for example, plesk is terrible at providing php updates. 3) Lots of people have an 'if it aint broke don't even touch it' attitude so will just leave the server as-is until something breaks.

Not only that, those stats are somewhat flawed. As people have become more security concious they've stopped their servers reporting server-side technologies used. This will inflate the statistics for older, rarely maintained servers where the defaults are set to report the tech used.


But not every 12-18 months because of breaks in the language. An application usually only gets rewritten in the same language when the existing codebase cannot be maintained, or because of a drastic change in user requirements. In some cases an application gets rewritten because it is the only way to move to a new platform, but in that case it may also mean a change in language.

The average life of an application is said to be about 7 years, and some have been known to last much longer than that. My framework has existed for over 10 years but it is still going strong because I actively maintain it with a new release virtually every month - and with an amazingly small number of BC breaks. My major ERP application is seven years old but it is still going strong because I actively maintain it. By "maintenance" I mean fixing bugs and responding to user requirements, NOT by refactoring my code just because some junior developer with OCD has had a brain fart and removed something from the language that did not NEED removing.


If I, a doddering old fart from the age of the dinosaurs who started his career on COBOL, do not have any problems dealing with such minor and trivial inconsistencies, then why can't a youngster who is obviously not long out of school do the same thing?


Wait, there are BC breaks between 5.3 and 5.4?


What you are saying isn't making sense.

PHP 5 has existed since 2004. So PHP 7 isn't a breaking change that was created within 12-18 months. PHP 5.0 through 5.6 has likely had very few breaking changes. You typically don't introduce big breaking changes in minor versions.

PHP 5 to PHP 7 is a major version change, those definitely have breaking changes (PHP 4 to PHP 5 had several too). Your framework has been 10 year strong because, well PHP 5 has been out for 10 years. It has nothing to do with the lack of breaking changes, you simply haven't crossed major versions yet.

I wouldn't suggest doing that, as you'll still have this problem with breaking changes. .NET, Java, Python, all implement breaking changes at major version upgrades.

You obviously have zero respect for those that created the language if that is what you think happened. I strongly suggest reading my earlier post as to why breaking changes are a necessity for any language.

No it didn't. That is another flaw in the original argument. smile All minor versions in 5.0 to 5.6 would have rarely had a breaking change (I bet you can count them on one hand -- if even that many existed)


Just because other languages do it does not mean that PHP has to follow suit.

While a break in BC may be necessary to fix a bug or security issue, a break for any other reason is frivolous and unnecessary.


Fairly certain I provided many valid reasons...

Surely you have to do similar tactics within your own framework, otherwise you end up supporting legacy implementations for way too long, which ultimately slows your development/QA process.


Sorry, this is me being a "smart-***" (so don't take this too seriously), so if I guess "It is because the solar panels of the international space station are being affected by cosmic radiation and that limits the communication here on ground with the rest of the team" does that mean my guess has as much merit as yours since I derived it from the same data elements of 65% still haven't upgraded?

No, it still is a completely wild guess with nothing backing it. smile


Then your understanding of the release numbering system is flawed. Going from 5.3.x to 5.4.x is a major release. Going from 5.3.x to 5.3.y is a minor release.

If you look at you will see a whole page full of backward incompatible changes for the move from 5.3.x to 5.4.x. There are similar lists for all the other major releases.


No, fairly certain you are wrong on that.


Many drop the .Build purely because that is only useful to developers, which leaves Major.Minor.Release

5.3 is a minor release of the PHP 5 language. So is 5.4. Then you have 5.4.1 which likely have hotfixes found in 5.4.0 (or prior minor/release versions, such as 5.3.4).


There's no way to accurately answer that. However, it's irrelevant. The fact is, PHP does have a fight on its hands here and it needs to keep up. PHPNG simply wouldn't have happened if it wasn't being pushed by Hack.

Needless to say, as developers this is a good thing because we get much needed improvements to the language we use every day.

Define "inefficient". Where are your benchmarks to prove the saving that the removal of PHP 4 constructors would bring?

if (method_exists($class, '__construct')) $class->__construct();

is always going to run faster than

if (method_exists($class, '__construct')) $class->__construct();
else if (method_exists($class, $class->name')) $class->{$class->name}();

You could scan the class once and store the result of the if statement (using extra memory for each defined class) or do it each time an object is instantiated. Either way it's going to result in either higher memory usage or more processing

Define "minimal". What are your sources?

I've looked at probably hundreds of PHP libraries over the last few years, I've not seen PHP4 constructors used once. Have a look at PHP projects on github, I bet you can't find even 10 of the thousands on there that are using PHP4 constructors (and are not clearly using the php4 object model, e.g var $var)


Why should anyone have to? My great grandparents did not have problems dealing with a house without central heating, why shouldn't the current generated be expected to do the same?

You're actually arguing in favour of inconsistency? I'm convinced you're trolling now.


So the difference between a language that is used on 240 million website and one that is used on less than 24 is irrelevant? A fight between an elephant and a mosquito will not be much of a fight.

I have seen the list of improvements in the internals list, and I am in favour of all of them. However, none of these "improvements" require the removal of PHP 4 constructors.

It sounds like this problem could be fixed by if it were amended to include (the still supported and as yet undeprecated) PHP 4 constructors. You see, it is possible to fi the problem without resorting to a BC break.

Oh I see. Your statement is based solely on the numbers of scripts that you have personally seen. Are you aware of how many PEAR components were written for PHP 4 and have never been updated to use PHP 5 constructors? I have seen posts from other developers in other forums who have large applications which were written using PHP 4 constructors and who simply don't have the time to refactor them.


Your analogy is worthless. Comparing changes in methods of central heating with dealing with minor inconsistencies in a programming language just does not carry any weight.

I certainly would not be in favour in creating any new inconsistencies, but I am not in favour of breaking the language to remove minor inconsistencies that have existed for decades and which do not cause problems for most developers.


I think this is going to be the most important part. I'm really inclined to doubt this is a significant number of people.

Is anyone still using PEAR? PHPUnit just deprecated its PEAR install, and I'd much rather use Composer than PEAR for basically anything.

Edit: Let me rephrase: is anyone who is going to upgrade to PHP7 still using PEAR?

Anyone who's starting a new project is not using PHP4 constructors. Anyone who's got a legacy project isn't going to upgrade to PHP7. I really fail to see what the issue is.

I would suggest removing PHP4 constructors isn't going to cause problems for most developers.


That doesn't bother me at all. As I have already said in a previous post I changed my framework

Then you have shot down your own arguments here and proven that your position is entirely from an emotional and nostalgic perspective. The fact that you happen to use PHP4 constructors and don't want to use __construct() is the basis for your argument here.

If you were really interested in arguing for "backwards compatibility" then you'd be arguing tha mysql_connect should just be rewritten as a wrapper for mysqli_connect; function mysql_connect($args) { mysqli_connect($args); }

Let's put it this way, the only valid argument here is that it would mean some developers have to change their code. However:

  • Changing a codebase would take minutes (There was even mention on the mailing list of providing a script that did it for you), considerably less time than testing the code against the new version

  • The majority of developers do not use PHP4 so will never be affected

There's not really a case for keeping them. Having two ways of doing the exact same thing is pointless and just adds bloat to the language.


Again, so we're expecting them to upgrade versions but not their code? Come on...


And how many of those BC breaks caused pain to their customers, the application developers? Breaking the language for the convenience of the language developers should be weighed against the inconvenience caused to the application developers. If there is too much inconvenience then the convenience should be shelved.


Errmm, That's why they call it "work" wink

I've been writing code for a few decades and in more than one language. What do I expect of any given language?

If it's Beta, I expect breakage happening at some point, likely sooner rather than later.
Once out of Beta, I expect there to be minor releases for bug and security patching.
Given a DEPRECATED notice with a fair amount of time for me to adjust code is appreciated, but not expected.
Changing to a major release, I do not get surprised if things break, A major release is by definition not guaranteed to be backwards compatible.

If I want to change to a major release, I expect that I will likely need to adjust my code.
If I don't want to adjust my code, I don't change to the new major release version.



Yeah, we should definitely not change the language because there are bad tutorials on the Internet.


Tell that to the site owners whose applications suddenly stop working. They don't know why it stopped working and they don't even know about any script they need to run.


Then don't upgrade? You shouldn't upgrade your production box without checking how well your code runs on it to begin with. Doing so is always dangerous, regardless of how "stable" you feel the language is.

So are you saying if the PHP devs mark them as deprecated in 5.6.X you'll be okay with it? As I doubt that. Plus I have a feeling deprecating a constructor syntax is much more difficult than deprecating an actual function/method. I'm sure it can be done, but it isn't as easy as marking a function with [deprecated].

Which languages? As again, look at all of the other web related languages, .NET, Java, Python, Perl, etc. (either in past or present versions) All have introduced breaking changes at major versions.


You mentioned that you worked in COBOL. I know quite a few COBOL programmers around my age (25-35) and all of them work in the 1978 COBOL Standard instead of the 2002 OOP Standard, because the 2002 Standard breaks everything.

They also all hate their jobs.

I think you're just making stuff up at this point.


You missed the point. smile All languages eventually incorporate breaking changes.


I specifically said that "in my experience" I never encountered any upgrades that included BC breaks.


If PHP 7 deliver on the performance, which looks very promising already. Its adoption rate on the enterprise and professional level will be very quick even if they decide to add a lot of BC breaks.

I am surprised you do not put more weight on this, since it easily means thousands of dollars saved a month for anyone running a larger system. Even for smaller systems, it can mean the difference between having to move to a larger server, compared to being able to stay on the old one.


Not the point I'm trying to make. To properly test PHP versions, you need several things. 1) that version of PHP installed, and 2) your code base installed on that server as well.

That gives you a few options, 1) setup VMs (slightly expensive), 2) physical servers (most expensive), or 3) Vagrant (which is still VMs, but can easily be torn down)

For all of the options above, you still have to spend time setting them up, ensuring your codebase is installed properly, database seeding so you have data to work with, etc.

I'm purely saying the effort to properly support older versions of PHP at some point becomes too expensive and therefore, businesses drop support for those versions. Their money is better spent on more up-to-date versions that their internal servers already run on, or were upgraded to.

I know many places that only support the last 2 or 3 5.X versions of PHP. Because that is what they choose to have as physical/VMs/Vagrant setups in their environment.

This is purely a business/financial problem, not a coding problem. Sure the code may run on older versions, but the time you invest and pour into properly looking into issues on those older versions is downright expensive (if you choose to test it right and run it on the actual version the bug/problem/issue was reported on).

I see.

I'm not 100% in agreement here, because as programmers one of our jobs is to write maintainable code too and to write code that is easy to understand/update, which means refactoring it should be easy.

Any time I get a new feature request, we look to see if where that feature is going to reside can be refactored to better incorporate what the original requirements were for that area to what we are adding. I can only probably say a small handful of times we were not able to refactor the code to function better given the new feature we were implementing and how it played into existing logic/code (and maybe you do this too, as you didn't specifically say you don't).

Look at it from the other perspective. The ones who choose to use them, do so, because the benefit they offer outweighs what it costs to support the older versions of PHP. It isn't only because they want to use latest and greatest, if they are anything like the projects I've been a part of, there is an uphill battle discussion the benefits those features contain because doing so, would definitely drop support for older versions of PHP. Although it isn't a difficult argument to show that properly supporting old versions of PHP is expensive, not many companies jump on that right away, but when you show the numbers and the cost savings, it is hard for a company to argue too much that they are throwing money down the drain that could be used towards implementing larger features sooner than later.


In my experience a "web site" is open to members of the public whereas an "enterprise application" is only available to members of that organisation

Seniority provides experience which juniors simply don't have. But there are pros and cons to both categories - some oldies refuse to embrace change while some newbies want to replace everything old with something new without realising the consequnces.

It depends on what has been broken and how long it will take to fix it. Guessing that it shouldn't take long is just that - a guess - and as reliable as a politician's promises.

You are still missing the point I have been trying to make from the very beginning that this particular proposed BC break is totally unjustified and should be given the big "E".

Very few BC breaks can be fixed simply by running a little script.



The proposal to remove PHP 4 constructors from PHP 7 was not made because they cause genuine problems - because they don't - but simply because some purists don't like them. As for how it integrates with the lifecycle of several companies, this is only relevant if they are currently using PHP 4 constructors and have to change their code. If the are not using them then this proposal will have zero impact.

I am not against improvements per se, but I am against removing perfectly valid functionality for no good reason. The reason that I am still arguing is that the RFC has not yet been voted upon, and my voice may still have some impact on the vote.

If other companies have issues because of the way that they do things, and | avoid those issues by doing things differently, why is it wrong for me to point this out?


Are you the same Tony Marston behind Radicore? Is this an example of what you consider to be well structured and easy to read and maintain code?


For major releases of any software (taking PHP as an example from 5.x to 7.0) I would always expect there to be major changes to things and for some backwards compatibility to break. There has to come a point with any given version of a software package that the developers say "as of we will no longer support version of " it'll be a split as to the cost of maintaining old codebases and the time taken to maintain them.

I personally see the removal of PHP 4 constructors as a very minor change. I believe that the __construct() was introduced around 6-7 years ago, given how minor a change that is to any classes and the time that __construct() has been around tbf I can't think of any good reason why any PHP classes haven't been updated from PHP4 style constructors over to __construct(). If I was looking for a class to use for something and I saw a PHP4 style constructor (or the old mysql_* extension), it would be sent straight to the Recycle Bin.

If I was doing PHP programming as my job, I wouldn't support at all any version older then 5.4 and once PHP7 came out I'd tell any customers that I'd be ending support for 5.4 at some point (probably six months after the release of PHP7)

Off-topic: Just flicking through if I was viewing that code for the first time the use of addslashes() would raise a red flag for me and unless it's escaped elsewhere the use of user submitted data in the database without escaping it would raise another red flag. imo there is no valid reason to not be using prepared statements when dealing with user submitted data


It depends, if a customer says his/her server runs on PHP 4 or even PHP 5.0-5.2, I will tell him/her to upgrade the server, or to switch to a better webhost. Because its not worth compensating for those minority of customers who do not contribute much to your revenues/profits or popularity anyway. Just like when you charge a price for your product, there will be customers coming to you saying 'I want to buy your application, but my pocket only has this little amount of money'. Do you care about this complaint? Maybe, if your price really is too high and is driving too many customers away. But no matter how low you set your price, there will always be potential customers unable or unwilling to pay as much, then they just have to walk away and chill.

That's the law of nature, you do not compromise for the absolute minorities. Of course, my software will continue to support PHP 5.3 for a while, thats only because PHP 5.3 is still the predominant version of PHP installed on webhosts. Once most webhosts move to PHP 5.4, support for PHP 5.3 will be dropped too. As far as I know, CakePHP 3 even already drops support for PHP 5.3 and requires PHP 5.4. Each developer/framework may have different opinions on whats the minimum PHP version to support/maintain, but there's always a minimum. You cannot support all versions anyway, do you even remember how PHP 2 or PHP 3 looks like? Nope, you wont, and you will tell me that essentially nobody is using PHP 2/3 nowadays. Okay, I can say the same for PHP 4, or moreover, anything below 5.3.

Yeah you understand this, and we can apply the same logic to the PHP internals. You are entitled to have your opinions, and similarly PHP internals are allowed to have theirs. Because your opinion is minor and opposite to what the majority of PHP community is looking for, the PHP internals will not worry about your protest against the removal of PHP 4 constructors and any other backward incompatible changes.

Honestly, what surprises me the most is that you actually make a big deal out of this PHP 4 constructor removal issue. Just as the poster before my current post said, almost nobody seriously cares about this. I wont advocate for PHP 4 constructors removal either, but unlike you worrying about backward incompatibility, my reason is that I dont care. In fact, before you brought up the PHP 4 constructor thing I almost forgot that one can actually write constructors in a different way in PHP. Ah these old days, but seriously whether or not PHP 4 constructor is removed or retained, it will make little to no difference for most of the PHP developers. So just relax and chill okay? Its not really worth arguing at, for some things that pretty much no one truly cares.


Yup, SQL injection vulnerabilities. Mail header injection vulnerabilities. Global variables up the wazoo. Control logic mixed with DB logic mixed with validation logic mixed with... pretty much every other kind of logic. And did anyone else notice he invented his own password encryption? He's basically made every amateur mistake in the book. And, guys -- I did this for your benefit. If he ardently defends this code as well structured, easy to read, and easy to maintain, then you've got to know you're never going to get anywhere in this discussion. PHP will continue evolving despite Tony's objections. Let's be happy with that.


Do you know what PHP originally stood for? "Personal Home Page". It was created as a rather simple and usable language for people who were not professional programmers, to be able to create a usable server-side program.

It did improve with professional input, even through the time Zend became the de facto parser, but the handwriting was on the wall. PHP has grown into a monster, co-opted by full-time professional programmers who just cannot stop improving it. They didn't like spaghetti code so they created OOP, and then came these gigantic libraries and platforms.

If the programming world really needed another impossible-to-use-if-you-are-not-a-professional-programmer language, why didn't it just improve ASP, or invent something else? Now, the pointy-headed committees are going to start deprecating "legacy code".

Nobody minds that PHP is improved in ways that make it usable for giant megaliths like Wordpress. But I did want to voice one tiny little objection to the complete insensitivity the "new" PHP community shows to the roots of the language. Why do they insist on deprecating the old root code? Does nobody realize that it has a function other than building gigantic complex sites and that there are people who use it for exactly what the name actually stands for: Personal Home Page?


PHP's evolution is a consequence of its popularity. If people only ever tried to write small, one-off scripts, then PHP would have stayed a small, one-off language. But people kept getting more ambitious. Wordpress, vBulletin, Wikipedia, and others. People wanted larger and more complex applications, and they often required skilled and professional programmers, as well as new language features to help manage the complexity.

But the good news for you is that you can ignore most of that if you really want to. You don't have to use namespaces or closures, nor OOP or autoloading. You could ignore all that stuff and still write a simple, procedural, one-off script. You could even write a mostly HTML page with bits of simple PHP sprinkled in, just how Lerdorf originally intended. The new language features don't block you from doing that.


It's literally one search and replace away, no matter the size of the codebase, and you'd improve your site's security immeasurably.


Way to completely ignore people's valid criticism. You have all of the experienced programmers here saying your code is poor quality. Objectively it is, it is full of bad practices.. not all security but it's needlessly difficult to maintain. The length of your methods is a serious indicator of problems without even digging deeper[1][2][3][4]. On inspection, it's quick to see that your code is mixing all kinds of irrelevant logic as pointed out by Jeff Mott earlier. It mixes several concerns that really shouldn't be. Let's quickly deconstruct:

 $GLOBALS['task_id'] = 'logoff';

There is not even potential for debate about global variables[5][6][7][8][9][10][11][12] so this is an instant and serious red flag.


The same is true of singletons[5][13][14][15][16] so that's another serious design flaw... and we're only a few lines in!


Presumably the skip_validation property is in the parent class. Inheritance breaks encapsulation[17][18]. While a much more minor infraction than singletons and global state it's still badly designed code.

if (is_True($external_auth_off)) {

You actually have a function called is_True? Redundant and pointless. I was going to carry on but I feel the more nuanced flaws will go over your head. Many of my second year students would have been able to identify several flaws in this code.

I'll leave you with this: Ignoring the security flaws and bad practices. It's impossible to reuse any of that code and use a postgre or mssql database. It's also impossible to make your login class use OAUTH or similar. It's inherently inflexible and difficult to change.

Claiming "experience" and "seniority" in your posts above and then admitting to authoring code like this instantly negates any claim you have surrounding skill and understanding.

[1] Fowler, M (2006) CodeSmell,
[2] Hevery, M (2008) Flaw: Class Does too Much.
[3] Bryton, Sérgio, Fernando Brito e Abreu, and Miguel Monteiro. (2010) Reducing Subjectivity in Code Smells Detection: Experimenting with the Long Method. Quality of Information and Communications Technology (QUATIC), 2010 Seventh International Conference. IEEE.
[4] Carneiro, F., G., Silva, M., Mara, L., Figueiredo, E., Sant'Anna, C., Garcia, A., & Mendonça, M. (2010). Identifying code smells with multiple concern views. In Software Engineering (SBES), 2010 Brazilian Symposium on(pp. 128-137). IEEE.
[5] Sayfan, M (n.d.) Avoid Global Variables, Environment Variables, and Singletons
[6] Hevery, M (2008) Flaw: Brittle Global State & Singletons.
[7] IBM (2012) Avoid modification of global and static variables
[8] Koopman, P (2010) Better Embedded System Software. ISBN: 978-0-9844490-0-2. Drumnadrochit Education LLC.
[9] Svennervberg, G (2012) Global Variables Are Evil
[10] Zakas, N (2006) Global Variables Are Evil
[11] Ferreira, G (2013) Best C Coding Practices – Global variables
[12] Crockford, D (2006) Global Domination
[13] Densmore, S (2004) Why Singletons are Evil
[14] Radford, M (2003) SINGLETON - the anti-pattern!
[15] Yegge, S (2004) Singleton Considered Stupid
[16] Hevery, M (2008) Singletons are Pathological Liars
[17] Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. ISBN: 0201633612. Addison Wesley. P.19-20
[18] Bloch, J Effective Java. ISBN: 0321356683


Which is exactly what a singleton is, a single instance of one class. "Some people" here is a red-herring. Singletons (and globals) have been objectively shown to cause problems (limited flexibility being the main one). Using them introduces problems in your codebase, which don't need to be there.

You can hammer in a screw rather than screwing it in. It'll work but it'll be a pain if you need to unscrew it again. A skilled tradesman will tell you it's a bodge job, the fact that you can do something in an objectively inferior way doesn't mean you should.

Programmers far more experienced than you. I provided several references, the most notable being the highly regarded Gang of Four book, but here's a few more:

Anyway it's clear that you're stuck in your ways and nothing is going to change that. I've provided references from academia, books and the blogs of professional programmers to back up my points. I suggest you read them.

As others in this topic have discovered, trying to have a meaningful discussion with you is futile so I'm out.


Well I've gotta say this Tony user is clearly a very unique type, browsing through his sites I find many articles that are totally opposite to the mainstream opinion on good practices, such as this one:

First time I heard DI is bad, I wonder if anyone is interested in discussing this. XD


Continuing the discussion from The PHP 7 Revolution: Return Types and Removed Artifacts:

haha wow. That article is so full of false equivalences and things that hint at poor separation of concerns. This line is a brilliant example of a fundamental lack of understanding of basic OOP principals:

If you're not using an object that was passed in then your class is doing too much[1] and you need to redesign the class or move some responsibilities around.

However, this actually gives us an insight into tony's position. He's building on top of a fundamental lack of understanding, so for the problems he's trying to solve (that exist because he is building on top of shaky foundations) his solutions to the (wrong) problems he presents are technically along the right lines: when you have cornered yourself by making a class that does too much, then in this example, it is better to load the dependency if it's needed. Of course that's only true if you take his premise as true that the problem is that dependency may not be used, rather than the original class is doing too much.

If you build your water pipes out of lead then a water filter in every house sounds like a good idea. Of course most people would choose to build their pipes out of something less harmful saving them time and money.



I'll agree that this is veering off topic. I am not opposed, however, to an honest and detailed discussion about some of Tony's work in a new topic. It feels to me like this is a dangerous situation which needs to be dealt with, and I think we should dissect the code and show the world what's wrong with it - not as a personal attack, but followed by actual examples and references as @TomB has done in most replies here. Let's, thus, leave Tony's other posts be in this particular discussion.


I am not the only one to question the validity of Dependency Injection. If you look at you will see a list of links to other articles which also criticise the idea of DI.


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.


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?


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?


You obviously haven't read my CV which states that I started programming in the late 1970s. That's probably before you were born.


You obviously didn't get the joke, as PHP has only been around for 20 years.

Seriously though, you're just defining the terms junior and senior to suit yourself, despite it having absolutely no relevance to the discussion at hand anyway. The number of years you spend practicing a profession has no bearing on whether your ideas or arguments have any validity.


This is a very good point. At least it means we can call tony a "Senior"... and we all know how well new technology and seniors work together ;p

If we're playing the 'experience' card, I've been programming professionally for 15 years, I teach at a university and I'm doing a PhD which is centred around code smell/bad practice detection.


umm okay, if this is what you believe. But still like I said, I never assumed that you were an incompetent programmer, the term 'incompetent' is very ambiguous and I'd rather use the word unmodernized here. As your later post indicates, you started programming a long time ago all the way back to 1970s, and your first programming language was COBOL, which was a procedural language. Its understandable that it must have taught you many concepts and habits that were common and acceptable at that time, but were no longer considered good practices nowadays, such as global variables, singletons, long functions/classes, etc. Also your understanding of OOP is very shallow and unconventional, as you believe using objects alone makes it OOP, while in fact its far away from that. Apparently coming from a procedural coding background was a huge obstacle for your transition into the OO world, as some old habits would not go away easily.

Anyway, a modernized programmer, however, learns new concepts and adapts with time. Thats actually why many coders are doing refactoring, since they learned new skills and practices that will help with their development in a long run. It's never too late or old to learn, but it seems that you treat it as personal insult whenever people tell you that you need to refurnish your coding skillset and do something differently. Years of old programming experience can be beneficial or detrimental, depending on whether it helps you write better programs now and in future. So honestly, I consider that your so called 30-40 years of programming experience a hindrance here, since you fail to adapt to the modern programming standards and instead holding on to your old inappropriate procedural programming mindset that was common in the 1970s but are more or less obsolete nowadays. The world of computer and programming changes and moves rapidly with time, and I find it surprising how you willingly stay behind. Perhaps you still do not understand the nature of this industry, but I dont want to make an assumption so I will stop here. Good luck.


Tony is right.

He doesn't need to refactor his application. He doesn't need to adopt the 'best practices' of our industry, or modern programming techniques and language features. As long as he's happy to maintain his legacy codebase, let him continue to do so as he pleases.

As I see it, best practices ARE worthwhile for developers who:

  • Want to develop software they hope will be adopted and used by other developers
  • Want to reuse some of the many high-quality, 3rd party libraries out there to be more productive and avoid re-inventing the wheel
  • Want to be employed in some capacity where they work as part of a team, and
    will rely on these standards to be able to collaborate on code with their

While it's true that best practices aren't unbreakable rules, most (if not all) of them have been widely adopted because they minimize the likelihood of problems and mistakes.

As an analogy, imagine a skilled and experienced steelworker who works on high-rise buildings. He might think "Ha, I know what I'm doing! Any competent steel worker doesn't need all this safety equipment and regulations, it just adds unnecessary time and complication to my work!". The the point of these guidelines is two-fold: less experienced workers will minimize their risk of getting into trouble by following them, and even the most experienced professional can make mistakes. Following best practices reduces your need to work harder to avoid problem areas.



  • Want their code to be easily understood/modified by others
  • Want their code to be as easy to maintain as possible
  • Want to make their code as robust and bug-free as they can

It's worth taking a step back and thinking about why practices have been deemed either 'best' or 'bad'. These practices have all been tried and tested with the results reported by numerous academics and professionals who have fallen into holes and found themselves having to rewrite large sections of code because it was built on foundations which made it difficult to maintain.

Pointing out "This is a bad idea because it stops you being able to alter the code to do x later on and you'll need to rewrite it or a hacky workaround" is essentially what a 'bad practice' (or "code smell" or "antipattern") is.

Tony's clairvoyance apparently allows him to guarantee the client will never ask him to do x and that it will never affect him.


Why, then, are you so hesitant to try these practices we all speak of, and to accept the problems in security with your approaches even after having been given the materials that clearly demonstrate their substandard design?


Yeah I totally agree, practices are deemed good or bad for valid points, its the experience from hundreds or thousands of professional developers who have going through the problems again and again to figure out what should be done and what should not be done. People wont tell you that you should do this and should not do that for no reason at all. I am an advocate for design patterns, especially good design patterns, since they offer benefits that I will appreciate considerably in future.


You guys miss a very important point.

Tony has a different experience as he stated very many times, so the opinion of others does not matter that much. Also he has 35+ years of professional experience which places him around 55 years old. You wouldn't argue with your parents or grandparents about their way of doing things for one month non-stop telling them they are doing it wrong, would you? wink


“I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.”
― Douglas Adams, The Salmon of Doubt


You make a point, sure my parents and grandparents do some wrong things their own ways, but there is a difference since they aint public advocates. Of course I wont argue with them, because they are not standing in a public stage and telling other people that they should be doing their wrong ways because its correct in their eyes. If they are happy with what they are doing, its okay, but it becomes a problem when they start to tell people, especially the general public that their wrong ways are the approaches to take. If my parents or grandparents are public advocates for their wrong behaviors, I'd definitely argue with them since they will be effectively damaging the society. But they are not, and they never will, so this hypothetical situation is not meaningful anyway.

So you see, a forum is a public community in which we come to learn, educate and exchange ideas. It is not my house, in which I can do whatever I want to, good or bad, right or wrong. You can say the president sucks at your home or with your friends, no one will have a problem with it, but when you say it in a public area with lots of people coming from various regions and background, you will have to back up your claim with evidence why the president sucks. It's the same thing here. Like @fretburner said in an earlier post, if Tony is happy maintaining his legacy code, let him be. There's not a problem with that, but it becomes an issue(or more precisely, a war) when he starts to claim his code is superior and that the other people are doing the wrong thing instead. In fact, he does make an very interesting blogpost last year, very nice to read Id say:

Yes, it is when you start to claim superiority in front of public that you have to back up yourself with reasons for validity of your argument. Otherwise, people will counter, friendly or aggressive, which cannot be helped. Anyway, I am not interested in starting another argument with Tony anymore, I am just stating the reasons why people are arguing with him. I hope you understand that, these arguments from previous posts do exist for a reason.