Obviously you have your own agenda here and it isn’t to actually discuss why this decision may have been made and how it integrates with the lifecycle of several companies. With that said, you’ve made it clear you don’t like the direction PHP is going, unfortunately, there isn’t much you can do as it has been decided (from what I understand).
My points weren’t about you or your application, but what other companies do. You have no experience in that regard, that is my experience, so to say it was wrong or incorrect is an impossible statement for you to make. Since you don’t seem to care how others deal with these type of changes and just want to rant. I wish you the best of luck, as you’ll need it to move forward (and should you switch to another language, good luck there too; as these “breaking” changes will continue to occur).
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?
Yes. What is the problem with that code? Are the function names and the variable names meaningful? Yes they are. Is the code easy to read? Yes it is. Does it have a simple structure which is easy to follow? Yes it does.
The fact that my code is not written in the same style that you use, or the fact that I don’t use design patterns in the way that you do, or interfaces, or dependency injection, or any of that other OO crap, does not mean that my code is unmaintainable rubbish. I have been maintaining it and extending it for over 10 years without issues. Other people have been using my code for years without issues. They don’t seem to have problems with it, but if you don’t like it my only response is “ask me if I care”.
The only universal definition of “crap code” which you will get out of any developer is “code not written by me”. I’m sure that if I saw examples of your code that I would find fault with it, but such an argument would not be germane to the issue at hand so I suggest we not go there.
I should also point out that I did not post those code samples on that site. The person who did is long overdue for a knuckle sandwich.
Again, you missed the point in its entirety. It isn’t about you! The point was to show you what others are doing today, their experiences, their real life scenarios.
I officially give up on trying to help you see how you can overcome this and will instead leave you to your own internal discussions, as you seem to only want to listen to yourself to begin with.
Stop making this personal, and look beyond what you’ve done for the past 10 years. To quote Jurassic park, you’ve spent so much time pushing and pushing through requirements and keeping your code “untouched” but you never asked yourself “should you?” (I actually like that quote now…)
Actual quote:
“Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.”
The whole point of this discussion is the issue of whether it is right for the core developers to remove something from the language for no good reason - in this case it is PHP 4 constructors - or whether they should leave it in and move on to something more important. You, and others like you, keep telling me that I shouldn’t be using PHP 4 constructors because they are obsolete (which is technically wrong) and instead of wasting my time arguing I should simply get on with changing my code. That attitude sucks, and telling me about the problems that other developers have each new PHP release will always provoke the response that I don’t have the same problems as they do because I work differently. I don’t have a problem supporting different PHP releases with different versions of my code because I can support all releases with a single codebase.
As for that movie quote, it can also be applied to the core developers.- just because they have the power to break BC does not mean that they should. It can also apply to each new PHP release - just because it contains new features does not mean that I have to use them.
Thats a bold statement, for what reasons do you think only your framework is capable of writing enterprise applications? I’ve never seen anyone defining a capable framework as something that can run on all versions of PHP, you are an eye-opener. I dont think the other developers are incompetent, it is you who fail to see what it takes to develop and maintain a good framework.
Thats your opinion, and the majority of PHP coders do not buy into such opinions. Again like I said before, the capability of running on any version of PHP never was and never will be the criterion to judge the quality of a framework/codebase. You may not believe me, but take a look at this thread and elsewhere, does anyone actually support and defend your opinion other than yourself?
You dont have to, its a matter of choice. But many other people would want to do this, especially with good features such as namespace. You are assuming the industry works in exactly the very way you think it does, but unfortunately what you see is only a tiny picture of the software industry. Also keep in mind that whatever works for you, may not work for others. PHP, or whatever programming language, is developed for the majority of coders to write effective programs, it is unwise to conclude what it needs based on your own perception.
I never said that mine is the “only framework”, just “the only framework that I am prepared to use”. If other people choose to use a different framework then that is their choice. I have had brief contact with other frameworks, but AFAIAC they all suffer from the following major problems:
They are not true frameworks, just a collection of libraries.
They were written by website developers to build public-facing websites, not enterprise developers for building enterprise applications. The two have totally different needs, therefore require different frameworks.
They do not offer the speed of development that my framework does.
I had already built a framework in my two previous languages, so I rewrote it in PHP just to prove to myself that it was possible. Then, having built it, I used it to build applications. It still out-performs all other frameworks that I have seen.
There is no rule which says that as soon as a new version of PHP is released with new functionality or new syntax that I must immediately refactor my codebase to use the new features. I only use a feature of the language in my application if it actually provides something useful in my application. For example, I only use the mail() function because I want to send an email.
I disagree. If a potential customer comes to me and says “I want to buy your application, but my server is still running PHP version X” and I tell him “Sorry but it requires a minimum of version Y” then I have just lost a sale. If it comes down to a choice between code purity and making a sale which do you think is more important in the real world?
They are allowed to have their opinions and I am allowed to have mine. We much each be prepared to live with the consequences of our decisions.
Correct. The fact that other developers choose differently does not mean that my choice is automatically wrong.
Namespaces are a particular solution to a particular problem. I don’t have that problem, therefore I don’t need that solution.
The reverse is also true.
Instead of “a majority of coders” I would use “all coders” as the sole purpose of any programming language is to write software, and any software which is ineffective is totally useless.
I agree wholeheartedly that the purpose of a programming language is to enable programmers to create cost-effective software for their customers, but programmers also expect stability and longevity from their language as this then adds to the stability and longevity of their applications. A constant stream of frivolous BC breaks is a bad idea as it changes “to write effective software” into “to re-write existing software”. Notice the subtle change from “write” to “re-write”. Writing new software is one thing, but having to take time out to rewrite existing software just because some idiot broke the language is not an expense that most customers are prepared to absorb without complaint.
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 http://pastebin.com/ujpUuN1r 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.
A good reason is that PHP 4 constructors have never been marked as deprecated which means that they are fully supported and I am allowed to use them. The fact that you don’t like me using them is irrelevant.
I can support all versions of PHP 5 - from 5.0 to 5.6 - with the same codebase so I never have to say to a potential customer “I’m sorry, I don’t support 5.2/5.3 or whatever”. If a new PHP release contains new features then I don’t jump in and change my code to include any of the new features as I would immediately lock out any customers who are still on an earlier release. You may not think that is very important, but I do.
That is the principle part of my argument. The core developers should not break BC because it is convenient for them, but because it has benefits to the rest of the community. That is the difference between a “necessary” BC break and a “frivolous” one.
Just suppose the core developers proposed a BC break which affected a huge part of your codebase and required a huge amount of effort to fix. Just suppose that the reason they gave was “you shouldn’t be doing it that way anyway”. Just suppose you thought that the reason was too frivolous and far from being necessary. Would you bend over and take it like a mouse, or stand up and fight like a man? If you don’t have any principles that you are prepared to fight for then you don’t have any principles at all.
I would consider an implementation of the Caesar cipher today to be more of an obfuscation attempt than an encryption (though it is a substitution cipher, so in theory an encryption).
Interestingly enough, it does not work with common characters as quotes in the content out of the box, nor will it work with non English languages (i.e. multibyte characters), even if they are added to the scramble variables. Due to not all of the string manipulation functions used supports multibyte charsets.
This thread is getting pretty heated, but the content is valuable, so rather than shutting it down I’m going to ask that you all keep your cool and remain professional.
And with that, I would like to vote for a lock on this topic.
We’re obviously trying to mix water and oil here, shaking the container ever more vigorously, without realizing they’ll never, ever mix.
Tony, I believe you should cool your phrasing somewhat. Everyone here has been as cordial as they can be, when all you’ve done repeatedly is tell people they’re inferior and junior to you, and that their applications are oversimplified crap. You insist on calling people names, you insult our way of thinking about code and you generally refuse to even give it all a chance.
Having looked at your code in the two pastebins from this article, I can agree with the others on that it’s not well written, and highly insecure. In fact, I am convinced that you have not had a serious breach yet merely due to the fact that your app isn’t a popular enough target. With you representing such code, and us on the other side of the spectrum, it is clear we will never, ever agree, and nothing productive can ever come of this discussion, unless you compose yourself and start treating people with respect, regardless of how junior to you they are.
Like someone said, “It takes more energy not to change, because everything else changes around you”. I, for one, am out of energy to spend on this particular discussion.
I don’t want to close this thread unless I really have to, so could anyone else responding here please make sure it’s on topic, friendly, thoughtful and not-at-all-troll-like. If that doesn’t happen, I’ll shut it down.
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?
They have. There are more than a few languages that are heavily used in app development. Node.js, Ruby, Python, Go, Erlang, Scala, etc.
I’ve always felt the same way as you. I don’t see why people insist on taking a simple little scripting language and trying to do so much with and and try to shoehorn it into applications it was never intended to be in. PHP is a great language for little 1-off scripts, why’s it got to be anything more than that? It kinda became what it was because it was better than Perl and that’s what Perl was great at too. There’s so many better options for larger applications and I feel that this new group of people behind PHP have completely lost sight of what it’s good at. It’s definitely a “Me Too” attitude.
(I actually like that quote now…)
There are more than a few languages that are heavily used in app development. Node.js, Ruby, Python, Go, Erlang, Scala, etc.