3 ms·
https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-string.html https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st... Many of the PHP extension
by lowercased 6y ago
https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-string.html https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st...
Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no?
> Any new user coming from reading an older blog post or perhaps a PHP book would have no idea that that "older approach" is out of date
You could mostly get that from going to the PHP doc site itself, which would indicate things that are deprecated. Or your IDE might tell you.
Or, for things that are really out of date, like mysql_real_escape_string, they simply ... aren't in the language any more, having been removed completely from PHP7 several years ago. If someone is starting brand new today using a blog post walking them through setting up PHP5... they'll have much bigger problems.
There's a shitload of 'tribal knowledge' around stuff in many languages - you find out a lot of that stuff via searching. If I read an 'older blog post' on Go from 2015, and complained that my Go didn't work very well (or was insecure, or whatever), how much blame should the language itself take?
- 14u2c 6y ago> Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no? Don't most ecosystems use some type of namespace for that instead of exposing everything as global functions? Those practices were quite late to the PHP community.