Yeah, I'd have to disagree, to a certain extent. I think that to say that serving the end user completely as a programmer is a great thing. But to say that A) Coding is "just math" is completely incorrect. Coding is working with a language. A real programmer is a Creative individual, not necessarily an Analytical individual. It takes analytical skills and talent to realize what you need to program. But a good line of code is an elegant, poetic, wholeheartedly joyous expression of logic, efficiency, and your own Voice as a speaker of programming language. B) To ask that developers have the same skillsets as designers / graphic artists / branding specialists / etc. etc. is just really... Unreasonable. A basic conceptual understanding, sure. But I'll NEVER know what someone with a BFA degree knows. Not even a thumble's worth. And that's as it should be.
At the end of the day, trying to be "good" at both disciplines is going to leave you severely lacking in either one area or the other. And that's why I mock job postings that read along the lines of "We want you to know everything from doing print catalogs to how to performance tweak a database". Those are _at_least_ two different people.
I can think of 300 sites that need to be re-coded off the top of my head if this is a hard stop on it. And I don't have time for that. Nor does anyone else. I understand what they're saying, and I understand the need to migrate over time ( i.e. stop using mysql and move to mysqli today ). But they need to be cognizant of how many hundreds of thousands of sites this will potentially effect. This is a security origin, but the effects would be felt in business bottom lines. if ( $hard_stop ), just to reiterate that...
At this point, the mysql extension has been a "don't use this, you idiot" for nearly a decade. I have no sympathy. None. Choosing to write bad code when examples to the contrary are all over the place means that when somebody finally Does The Right Thing, you will be in for a world of hurt.
Besides, I'm sure some well-meaning soul will come up with some API-identical library or another to drop in. Yes, it'll still take time; consider it penance for screwing up.
But as noted by a sibling comment, it's deprecated instead of being removed. You have plenty of time to not fix your sites, I guess.
A simple shim wouldn't be too difficult as the mysqli extension is very similar to the mysql one. Off the top of my head, you could try something like this for a quick & dirty way:
So, don't update to PHP 7 until you can change stuff? They're deprecating it now, but it's not even going to throw a warning before PHP 6, if you read the post. Deprecation moves slowly, and they won't outright remove it for a another few versions, so even if they do remove it for the hypothetical PHP 7, that'll be fast. (In the several years category of fast). Look how long it took them to remove magic_quotes. They've been telling people not to use that for years and years.
I mean, you can all but to mysqli with %s/mysql/mysqli/g if you wanted to be lazy about it. Most the mysql_ functions have mysqli_ equivalents. (But really you should be using the OO MySQLi at least, preferably PDO anyway).
Excuse me, but you seem to be under the mistaken impression that if this change goes through, the PHP project will forcibly upgrade the PHP installation on these small sites.
This is a change for future PHP versions. It will in no way affect the version of PHP the sites you refer to run, unless they run said future version, which is impossible. I'd suggest you remind the businesses that own these sites that there would be absolutely no reason for the to upgrade PHP versions if the software they're currently running satisfies them.
The problem with the NOOP solution is that most of the small sites (the ones with nobody doing ongoing maintenance) are hosted on managed shared servers -- avoiding an upgrade isn't an option. The site owners will just wake up one day to an inbox full of UR WEB IS BROKE emails if they're lucky, and may even understand enough of what the ISPs first-level help desk drone tells them to get it fixed. (I imagine, though, that accusations of extortion would be more likely, since the quick fix would be a VPS with a non-refundable one-time setup fee.)
It's being deprecated; so it's not a hard stop. It says so right in the message: "Don't panic! This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now"
The mysqli extension has been out for 5 years already, if you've got 300 sites that need to be recoded you might want to get on that. It's not difficult to switch from mysql to mysqli -- the API is very similar. But you have a long time; PHP 5.4 won't even deprecate it and it's not even released yet!
> I can think of 300 sites that need to be re-coded off the top of my head if this is a hard stop on it.
Do you understand written words? Because you don't seem to grasp the concept of deprecation.
> And I don't have time for that. Nor does anyone else. I understand what they're saying, and I understand the need to migrate over time ( i.e. stop using mysql and move to mysqli today ).
Actually, "stop using mysql and move to PDO/mysqli" has been the recommendation since PHP 5.0 was released.
It happened 7 years ago.
You only have yourself to blame.
Oh, and since you don't care for not-broken APIs, it's not like you'll have to migrate your sites to 5.4 (let alone 5.5), you can just stay on 5.3. There's no mandate here.
If you are a language maintainer, and you have a choice between removing a dangerous feature and not removing a dangerous feature, what should you do? At some point, you have to realize that languages and libraries which enable you to readily and repeatedly shoot yourself in the foot are a Bad Thing.
There are tons and tons of hosts that still haven't upgraded to 5.3 - if the change comes in 5.5 or 6, it'll easily be 3+ years before it starts to be an issue.
I know for a fact that my old employer has one client who's still running 4.0, unless they've decided to pay out the ass to upgrade their spaghetti-coded system.
Considering that a) no out-ass money has been offered me, and b) I'm effectively the only person who could even fix bugs in the system, they're still running 4.0.
Reminds me of some places I've worked in my time. Clients made one site and wouldn't pay for an upgrade, and the folks running the company learned PHP when version 5 was brand new, and never wanted to upgrade because of a combination of clients not willing to pay and "seeing no need to upgrade".
Most of them are amazingly still in business, and their clients sites are still amazingly vulnerable. And we wonder why PHP has such a bad rep.
Sad but true. I love PHP, but it's like the Internet Explorer of (web-)server side languages. First there was the ordeal of dragging folks off 3 and onto 4, then 4 to 5, now 5.2 to 5.3 ... I look forward to writing PHP 6 code in my hovercar ;-)
> I can think of 300 sites that need to be re-coded off the top of my head if this is a hard stop on it. And I don't have time for that. Nor does anyone else.
The linked email repeated a half dozen times that this would be "soft deprecation", affecting the documentation, not throwing any error in the code.
How, exactly, would that "break" any sites on the Internet?
Wow. This is a really ugly workaround for a problem that began when you started using MVC. I would assume that any savings in db calls is completely wasted in processing overhead. Even more was wasted just coming up with this rigmarole. More reasons why MVC is bad juju.
With respect I think you have missed the point a little. The thing this idea solves is separating data-fetching optimisation from code layout. Regardless of whether you use MVC or entirely procedural code, it gets very hard to keep data access optimal when you have very complex and highly modular pages without introducing hacky globals or coupling unrelated parts of the code together (should be obvious why that's bad).
For any one page you may be able to change the structure so that it is more efficient without compromising the code too much but some of those modules will need to be reused in a completely different context on a different page.
I'm perhaps not explaining very well but this idea isn't solving deficiencies with MVC, it is solving a problem inherent in ANY attempt to modularise/re-use code. To gain the same data-access efficiency without MVC would leave your code unreadable not to mention un-maintanable with a complex site and high frequency changes.
Many sites simply don't need this so yes it would be overkill and of little benefit for them. I don't think the article was suggesting such a scheme would work well for everyone else. If you do have pages which legitimately need to make hundreds of queries/cache gets to resolve the data requirements though, techniques like this can help a lot.
At the end of the day, trying to be "good" at both disciplines is going to leave you severely lacking in either one area or the other. And that's why I mock job postings that read along the lines of "We want you to know everything from doing print catalogs to how to performance tweak a database". Those are _at_least_ two different people.