Hacker News new | past | comments | ask | show | jobs | submit login
PHP to deprecate MySQL extension (marc.info)
181 points by mildweed on July 15, 2011 | hide | past | favorite | 100 comments



Yes, yes, yes a million times yes. Every person starting PHP should be taught PDO with parameterized queries from the get go. The internet (and many respectable CS courses) are littered with examples using mysql_query() and string concatenation, half of which train people to create SQLI bugs or don't explain why escaping is needed; it's too late to undo the damage already done but at least people new to PHP will hopefully be told now that there is a better way.

If we had trained people to simply do

    $sth = $dbh->("INSERT INTO folks (name, addr, city) values (?, ?, ?);");
    $sth->execute(array($name, $addr, $city));
in 2005, when PDO first came out, uncountable SQLI bugs would have been avoided, and maybe lulzsec wouldn't be having such a field day in 2011...


Even that way is kinda fragile and fugly, though. I always recommend:

  $stmt = $somePDOObject->prepare("INSERT INTO folks " .
    "(name, addr, city) values (:name, :addr, :city);");
  $stmt->bindValue(":name", $name);
  $stmt->bindValue(":addr", $addr);
  $stmt->bindValue(":city", $city);
Slightly more verbose, but it has the upside of being more resilient.


I prefer:

    $stmt = $somePDOObject->prepare("INSERT INTO folks " .
    "(name, addr, city) values (:name, :addr, :city);");
    $stmt->execute(
      array(
        ":name" => $name,
        ":addr" => $addr,
        ":city" => $city));
since it treats the statement as a function call, rather than some chunk of state that you manipulate.


Totally forgot you could do that. Way cool.


Perhaps; to avoid any verbosity for any real code I wrap PDO in something like IdiORM and Paris (http://j4mie.github.com/idiormandparis/) or my fork called Dakota (https://github.com/powerpak/dakota). My point was that you can write a PHP + MySQL toy example with PDO that is just as simple as the mysql_query() garbage but is a million times safer in the long run.


Oh, totally, don't get me wrong. For a one-off query I might write what you did and think nothing of it. It's vastly better than the alternative.


If you go the resilient route with everything you end up with code that looks like Java code. It's not usually worth it, as when the query changes, odds are you'll be looking at the parameters, and will notice changes. Not true for large queries, of course, but for beginners? They're writing things like the above, where the entire process fits in a single eyefull. Making it more verbose from the get-go means they're more likely to just concatenate strings.


> If you go the resilient route with everything you end up with code that looks like Java code.

Meh. Prepared statements are useful when you'll use the it multiple times through rebinding, and for one-shots it's easy enough to have a function taking a parameterized query and an array and doing the annoying crap internally.

Then you just write:

    $result = executeSQL($somePDOObject,
        "INSERT INTO folks (name, addr, city) values (:name, :addr, :city);",
        array("name" => $name, "addr" => $addr, "city" => $city);


This is actually fairly close to what I do in my own code (I actually extend the PDO object, but same idea). The example I gave was just using the base PDO library instead.


What would be the difference, apart of the named parameters? I mean, does this add any security?


> I mean, does this add any security?

No, or he would have mentioned it.

It's clearer (especially as the number of parameters increase) and easier to change (in order to e.g. add a new parameter)


It's not more clear when you're trying to examine the codebase as a whole.


Of course it is. Names are clarity. Position-based binding sucks. I wrote a quick extension to java.sql.PreparedStatement at work one evening this week to enable named parameters specifically because of this.

Named parameters also make it easier to re-use queries (have a queries file or something) because you're much less apt to immediately break something by changing a query if everything is explicitly bound via names. And you can make the statements as a whole more terse if you'd like; I intentionally wrote it verbosely.


In the first example above, you have one place where you have position based binding that you could break while reusing or refactoring.

In your example, you have one place where you have position based binding that you could break while reusing or refactoring.


In my experience, people are vastly less likely to rename a variable than move it to a different place in a query.

There's also the proclivity for people to want to reuse the same value in multiple places in a query. Name-based binding makes that a lot more readable and straightforward.


resilient to what?


The ? ? ? example is readable when you're inserting three values; it becomes really really easy to leave off, or add on an extra, argument when you're inserting fifteen or fifty values.

Think fast: is everything in the code below correct? I've already forgotten whether I've added an extra ? or left one off, and I just typed this 30 seconds ago.

    $sth = $dbh->("INSERT INTO a_table (lorem, ipsum, dolor, sit, amet, consectetur, adipiscing, elit, donec, malesuada, purus, et, tellus, dignissim, tristique, in, ipsum, neque, ultricies, quis, hendrerit, ac, pulvinar, eget, enim)
    ) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?);");
    $sth->execute(array($lorem, $ipsum, $dolor, $sit, $amet, $consectetur, $adipiscing, $elit, $donec, $malesuada, $purus, $et, $tellus, $dignissim, $tristique, $in, $ipsum, $neque, $ultricies, $quis, $hendrerit, $ac, $pulvinar, $enim, $eget));


Trick question; you've specified the `ipsum` column twice anyway. ;)


I think it's a good idea to be abstracting this away anyway. you should have some light ORM that hides actual sql statements away, that way you don't run into this problem.

also, the named version above can have query length issues I think.


> The internet (and many respectable CS courses) are littered with examples using mysql_query() and string concatenation

Not to mention, "PHP: The Good Parts". I almost threw that book out when I hit those parts.


http://www.amazon.com/PHP-Good-Parts-Delivering-Best/product... ...Probably the right move.


Two things sometimes irk me: How much code there is to write for simple DB interaction + coupling of two different languages (SQL + [programming lang]).

In Rails I'd write:

  Folk.create(:name => some_name, :addr => some_addr, :city => some_city)
One line, easily readable and only one language (Ruby).

This is not meant to be a flame post - I'm just asking: Is it the preferred way in PHP to prepare SQL statements yourself?


It's only "one language" because the Rails framework is hiding the SQL away from you. You can bolt a framework on top of PHP too.


Well, if you use a PHP framework or library, of course there are easier and less verbose ways to prepare SQL statements.

I don't think RoR vs PHP would be an apples to apples comparison.


this reply isn't meant to be a flame, but-

Do you not understand why you can't compare Rails (framework) to PHP (language)?

PHP has frameworks with ORM, too.


ActiveRecord is an abstraction. Which is good in general, but when you want to get your hands dirty with some SQL it's a pretty serious hindrance.


ActiveRecord lets you write raw sql any time you need to. AR's design goal was to just reduce the drudgery, not prevent you from using the full power of sql.

No 'serious hindrance' involved.


I was having a hard time loading it, so in case it goes down, here's the text:

Greetings PHP geeks,

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 documentation team is discussing the database security situation, and educating \ users to move away from the commonly used ext/mysql extension is part of this.

This proposal only deals with education, and requests permission to officially \ convince people to stop using this old extension. This means:

- Add notes that refer to it as deprecated - Recommend and link alternatives - Include examples of alternatives

There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP \ way and main focus of future endeavors. Right? Please don't digress into the PDO v2 \ fiasco here.

What this means to ext/mysql:

- Softly deprecate ext/mysql with education (docs) starting today - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0 - Add pdo_mysql examples within the ext/mysql docs that mimic the current examples, but occasionally introduce features like prepared statements - Focus energy on cleaning up the pdo_mysql and mysqli documentation - Create a general "The MySQL situation" document that explains the situation

The PHP community has been recommending alternatives for several years now, so \ hopefully this won't be a new concept or shock to most users.

Regards, Philip


Would like to see the same for the 'memcache' lib, which is way older and slower than 'memcached'. The older lib comes up first in most search results and there's no real way for a new PHP user to know the difference.


The problem is that the newer/better extension, memcached (http://php.net/manual/en/book.memcached.php) relies on libMemcached (http://libmemcached.org/) and they won't release a Windows DLL for it (Google "libmemcached windows", the ensuing confusion is just the tip of the iceberg.) Until you can get PHP's memcacheD extension running on Windows boxes, there's no point to thinking about deprecating the memcache lib.

Sure nobody is really running any PHP sites on Windows boxes, but they're sure as hell developing on them. And while I get that the core PHP devs couldn't find a Windows machine if their lives depended on it, enabling coders on Windows machines is what brought them to their current size - something they've clearly forgot since http://pecl4win.php.net/ died.[/endrant]


I honestly don't understand why anyone would develop on Win and release on Linux, especially for a web-app.

VMWare Player and VirtualBox are free, and it's quite easy to setup an Ubuntu image that mimics your server platform (if you must be untethered)... alternatively put everything in the (private, if need be) cloud.


Pretty simply: I prefer the Windows environment to Linux. I don't like GNOME or KDE. I also don't really like the OS X environment, either. (My day job requires a Unix machine because our codebase is fragile, and it's a source of some annoyance.)

For my own projects, I would rather work in Windows, with a mild annoyance when testing, than consistently be annoyed by working in either. (I do use a VM for testing before pushing to production, but for quick "is this right" testing, bouncing Django on Windows and eyeballing it is generally good enough to keep pushing forward.)


You don't have to use Linux VM for anything other than PHP + web server.

You can still develop on Windows, just instead of testing on localhost, you'd test on local VM.


I realize that, and like I said, I do for final testing. It's enough of a roadblock to rapid development for me to avoid it until I have to make sure it will work on the platform. (VMware shared folders don't always play nicely, so I end up just pushing via hg.)


Once you've had a change to run in that kind of environment as a full-time job for 40+ hours a week, let me know...


I've been developing in a similar environment for over a year now. I have a linux VM running apache + associated software, with Samba running. I mount my code as a shared drive, and edit it that way. This means I get the power of linux + linux tools, but I can still run Windows as my primary OS.

I am perfectly happy with this setup, and haven't run across any downsides.


I've seen it done for years in a reasonably sized team. It actually works really well in a fulltime scenario on a large project, on decent desktop boxes in an office environment.

Developers appreciated that significant config changes boiled down to: get all of your local changes into version control, then grab the newest VM image off the network drive.

It's significantly more painful when you get out of that environment. If you have lots of projects, juggling VMs is a pain. They take up lots of space. Spinning them up/down takes minutes. You don't just have one working IP/hostname/Samba mount/etc that's always there. The resource hit from running a VM is a bigger deal on a netbook. Etc..


What is so difficult to imagine about an Ubuntu machine running server software?


I'm with you on this, but there's no need to even do it with vmare. Development boxes don't get slammed like servers, you can throw CentOS or whatever on a headless "junk" PC you found while dumpster diving, and upload your code to it for testing/development.

Hell, that's what I do and my main Desktop does run Linux, but I devel on a junk machine running Apache/PHP, PostgreSQL.


> Sure nobody is really running any PHP sites on Windows boxes, but they're sure as hell developing on them.

First part is somewhat false. Second part is very true.

Having developed, provided, and commercialized a WAMP server that was started in 2003 (http://www.devside.net/server/webdeveloper) I've gain some knowledge of who uses PHP on Windows.

Everyone. In all kinds of situations. There is absolutely nothing lost between hosting Wordpress on Windows vs. Linux. Security, performance, maintainability, etc.

I've also found that around 2009, half of the Apache, MySQL, and PHP downloads from their official sites where for the Windows builds.

These numbers have only gone up since then.

The Windows platform for PHP is critical to the health of PHP. Loose it, and you've lost half of the developers and about 30% of the production deployments.


I concur. A lot of people think memcache is the client and memcached is the daemon. Until you actually do some research and read the wiki page, do you understand that this is not the case.


Thus I am enlightened.


There's also a few other landmines like the "http" extension, which is not part of the standard distribution, and which is completely obsoleted by curl.


@mildweed: the title here is total clickbait. They aren't deprecating anything right now, it's not MySQL but ext/mysql (one of 3 possible mysql libs).

please remember in the future to do that better.


> They aren't deprecating anything right now, it's not MySQL but ext/mysql

MySQL is the "human-readable" name of ext/mysql.

Source: PHP's documentation http://www.php.net/manual/en/mysqli.overview.php


I see your point but you're nitpicking. MySQL is also the name for the database product, and so it's easy to read this and think that PHP are getting out of the business supporting MySQL.


> MySQL is also the name for the database product, and so it's easy to read this and think that PHP are getting out of the business supporting MySQL.

No, I don't think it is because it makes no sense at any level of resolution. MySQL is by a very long shot the most common pairing for PHP data persistence, unless the project is taken over by Microsoft (and drops support for anything but MSSQL) there's no way for such a thing to happen.

It simply is not a sensible interpretation of the headline.


Well, it's not a sensible thing to do, but it's a perfectly reasonable interpretation of the headline. That's why it's link bait.

[edit] fixed a typo


This is spot-on, and it's a shame nobody seems to care.


Well, somebody cares, if downvotes mean anything.


If only we could see the fucking points.


Not if you're a PHP guy. At least, among those I know about. The conversation I had when mentioning this went something like this:

"Oh nice, PHP is deprecating mysql." "What's the recommendation, mysqli?"

"MySQL" is often just used to refer to the extension in PHP parlance.


That's exactly what I thought. That's not the case?

(I'm a gamedev guy, not a webdev guy.)


Agreed, this was a very shocking/confusing/misleading title. "PHP slated to deprecate ext/mysql for newer mysql extensions" is much clearer, and far less exciting.


This is the kind of mess when you have 5 different libraries to do the same thing. PHP should never have allowed there to be multiple MySQL, Mamcache, etc. extensions.

Instead, they should have introduced the new libraries in a big version bump, and immediately deprecated the old and unsafe libraries. A couple languages / frameworks that are good at doing this is Apple with Cocoa, and Ruby / Rails.


And thus ensured that either you upgrade your version of PHP and instantly break your application, or that you stick with an older version with potential security flaws, and never bother updating again?

Bonus points if you're not actually in control of the version of PHP your web app runs on.


Being forever backward-compatible is a curse that prevents innovation and makes you end up with the mess of a language that PHP is.


I agree, but you don't have to be backward-compatible forever - you can deprecate features gracefully.


Only 5 different ways to do this?... that sounds like the most concise thing in ALL of PHP.


Definitely a step into the right direction! It's just scary how many bad developers are passing unescaped values into SQL statements.

I remember one guy who was a PHP developer at the company for years. He was really good at it though. However during my apprenticeship I asked him about best practices querying databases and showed him my code. Looking at it he said: "Why the hell would someone escape those values? It's a database, not the Pentagon."


I think people need to be educated that SQLI bugs (errors in escaping) lead to usability issues as well as security issues. I can't count the number of times I've searched for something on a clearly handmade site and watched in amusement as my search query grows backslashes while paging through the results. Also, single quotes show up in more places than people realize: I've seen them in proper names, street addresses, uploaded filenames... if those things break your app or damage data, that should be a tangible concern.


And my favorite place, email addresses. Valid. Rare, but valid.


This seems like a relevant time to have a discussion on the merits of PDO vs mysqli. Help all those who need to get off of ext/mysql make an intelligent decision on where to go next.

I'm less interested in features (data layer abstraction) and more interested in performance and security concerns.


> I'm less interested in features (data layer abstraction) and more interested in performance and security concerns.

They both offer the same security (though I believe mysqli offers more rope to hang yourself with, and PDO's API is simpler and smaller).

In the past, mysqli had the performance edge. It's probably still the case, since PDO is db-independent (PHP bundles a dozen of PDO db drivers in the standard distro) whereas mysqli is db-specific. Mysqli will also offer access to more db-specific features if mysql.

PDO has ditched the procedural style entirely (no PHP4 compat), has a smaller API and lets you use the same API for different DBs (across projects, so you'll hit a MySQL and a Postgres db using roughly the same query API).


Sorry if this is a silly question but where does MDB2 fit into all this? http://pear.php.net/package/MDB2 It looks like it uses mysqli already, is it superseded by PDO?


MDB2 has basically been supplanted by PDO, yes.


As a person who teaches PHP (and probably other languages too), you should definitely tell people not to do following mistakes:

  mysql_query("INSERT INTO table(field) VALUES('".$_POST['input']."')");
and not to forget, a truly classic one:

  include('pages/'.$_GET['page']);
When I started to learn PHP there was a contest between the students: Who brings hosts with vulnerable websites down faster. The trick was to recusrively include the same page (like index.php for example). The most funny thing though was to see the explosively rising load average by including /proc/uptime.

After having some fun, we usually sent emails to the administrators just to not receive any answers and to find the hosts still vulnerable months later...


I would consider e-mailing the administrators an e-mail with something along the lines of "<img src='http://vulnerable_host/?page=/proc/uptime />"

"The call is coming from inside the house!"


It was much more fun to send them their own /etc/motd!


I've never understood why you can't write secure code using string concatenation. It seems to me like all it takes is a reliable "quote" method (with proper escaping of course), and the discipline to use it on _all_ variables that go into a query. The advantage is that queries are sometimes easier to read and maintain when they're written locally like this, without having to jump down to another line to see what a placeholder will actually contain.

I concede of course that this can't work unless there is absolute discipline in a project to quote absolutely all variables, whether you think they are trusted or not.

Am I missing a key point here?


I wished there was a new PHP syntax that would escape strings before substituting them. Like this:

escaped_query="INSERT INTO t (a,b) VALUES ('$!some','$!thing');

The "!" means "escape this variable".

That would be the easiest way to create queries with escaped parameters.


Escape for what? MySQL? MSSQL? PGSQL? All have slightly different things that need to be escaped.


I've experimented with a variation of this.

Something like ...

  foreach($_REQUEST as $k=$v) {
    $REQUEST[$k] = mysql_real_escape_string($v);
  }

  $query = "INSERT INTO table VALUES('$REQUEST[email]', '$REQUEST[name]')";
Problem is, this only works if you don't plan on modifying any of the values before you stick them in the database.

You could also do something like ...

  $query = "INSERT INTO table VALUES('{$e('email')}', '{$e('email')}')";
  $e = 'esc';
  function esc($v) {
    mysql_real_escape_string($v);
  }
But I think that looks pretty ugly.


Hey, the {$e('$value')} idea is interesting.

old way:

  $sql_email=mysql_real_escape_string($email);
  $sql="UPDATE t WHERE id=123 SET email='$sql_email'";
your idea:

  $sql="UPDATE t WHERE id=123 SET email='{$e($email)}'";
Im not yet sure, which one I like more.


"to do that now"?... What would be a good time to break the majority of smaller sites on the Internet?...


Meh. They're just talking about deprecating it on the 5.4 horizon so far, not going to break anything


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:

    $f = array_filter(get_defined_functions()['internal'], create_function('$i', 'return substr(0, 6, $i) === "mysqli_"'));
    foreach ($f as $func) {
      eval ('
          function ' . str_replace("mysqli", "mysql") . ' {
            return call_user_func(' . $func . ', function_get_args());
          }
      ');
    }


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


http://gophp5.org

I can assure you the idea of shared hosts upgrading too quickly is a non-issue. It's 2011 and there are still shared hosts running PHP 4.


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!


> The mysqli extension has been out for 5 years already

I believe mysqli and PDO were released with PHP 5.0. That's July 2004.

That's 7 years ago.


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


I guess there is a business opportunity then to write a module with the old API that keeps working with new versions of PHP.


FWIW most of the mysql_ functions have a direct counterpart in procedural mysqli_, with the exact same API.

mysqli even features the real_escape_string abortion


Or just run a sed command and fix a (very small) number of errors that'll pop up. mysqli is almost a drop-in replacement.


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?


I am both amused and horrified by the reluctance of developers to officially deprecate the extension. One post even suggested introducing E_NEARLY_DEPRECATED to handle this situation. Why can't people simply say, straight-up, that it is deprecated, and acknowledge that that means that it shouldn't be used in new code? It's not that big of a deal, is it?


The problem is that this would be one of the most widely used PHP extensions being deprecated, so they're just being careful. This is not the normal way things are deprecated, but education is a good way to start the process of removing popular functionality from such a popular programming language.


Exactly. For something like ereg, it was a lot easier to just deprecate it and go from there. For mysql, it's such a commonly used extension that a softly, softly approach is needed, no matter how much it would be nice to get rid of it immediately.


If they do actually add E_DEPRECATED to mysql/ext they will probably have a really hard time every depreciating anything ever again.

mysql/ext is so popular that all default installations will start hiding E_DEPRECATED, which means that no one will ever again see depreciated warning even for things that are easy to fix.


Deprecation is a signal that it will be removed in the future, not an immediate removal. The entire point of deprecation is that it allows library authors to signal that a thing will be removed in the future, down the road, when everybody as switched to something better. If that mechanism isn't reliable, then apparently there is something wrong with the language community.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: