On Thu, Nov 15, 2012 at 7:26 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 11/15/2012 04:18 PM, Sherif Ramadan wrote: >> On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: >> >>> >>> >>> If it wasn't that active open source projects still have ext/mysql as their >>> primary connection today, I would agree with you. But we still have open >>> source projects, major ones, that still rely on it even in their dev >>> versions. Sure Wordpress may have a patch available, but will it work with >>> extensions? Likely not. >>> >>> Right now, it's just "discouraged for new development". Not "you really need >>> to get off it now". By adding E_DEPRECATED, you're basically saying "see, we >>> told you to get off it", when we never did. I think controlled communication >>> and collaboration with the involved projects would go a long way to >>> maintaining (and restoring to some extent) the health of the community. >>> >>> And it's one thing to have the warning that says "It's discouraged", and >>> having a warning that says "It's officially deprecated. In the next release, >>> we're going to start throwing deprecated notices if you use it. And the >>> release after that, it's going to disappear. So get migrating off it now". >>> They convey completely different things. The first sounds like "best >>> practices", where the second shows the gravity of the situation... >>> >>> >> >> I'm just trying to understand your reasoning behind this view. >> >> How is "telling people it's deprecated, but only in the manual" going >> to be any different than "putting warnings to discourage future use, >> but only in the manual"? >> >> 1) People who use mysql_* will rarely ever look at the manual to see them. >> 2) Even if they do they do what makes you think this is more effective >> than seeing the warning in their logs? >> 3) Even if it was more effective, what makes you think it will result >> in any kind of action beyond that of which the warnings would result? >> >> Sorry, I don't see any kind of indication that putting things in the >> manual is going to show "the gravity of the situation" any more than >> the deprecated errors will. > > The main argument is that we haven't actually made it clear in the > manual that the extension is going to be deprecated. There is a user > note on http://www.php.net/manual/en/book.mysql.php and a "This > extension is not recommended for writing new code" on > http://www.php.net/manual/en/intro.mysql.php >
Just to stress on what Philip has already mentioned below, that was my point. The main argument isn't a very good one. Thus why I disagree with it. Virtually every page that documents an ext/mysql function in the manual has (at the very top) a pink box that stands out and clearly states: "Use of this extension is discouraged. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information. Alternatives to this function include: mysqli_affected_rows() PDOStatement::rowCount()" This was the soft-deprecation notice that I believe was discussed before the actual steps were to be taken to officially deprecate ext/mysql. Yes, it's a suggestion, but a clearly worded suggestion, none-the-less. It has been around for a little over 5 months now. I think that's plenty of time to start alerting people to the fact that the deprecation is coming. Let's not forget people are not completely foreign to the news that ext/mysql has been under plans for deprecation since 2010. I've seen plenty of blogs and talks in conferences of the deprecation to come. At this stage we can begin updating the manual with "this extension will be deprecated in 5.5.0 and removed in the next release to come" and in the following X number of months that it might take to go from Alpha to Beta, to Stable release of 5.5 people will have advanced warning of the deprecation to come. > As Anthony mentioned, this is a very weak best-practice type of message > that we are only barely whispering here. To go from that to start > throwing deprecation warnings on what is perhaps the most heavily used > PHP extension ever is a rather drastic step. Your argument seems to be, > "Well, there is no point documenting it because people won't read it > anyway", which may be true, but we haven't actually tried that yet and > for something like this I think it should be the first step. > > -Rasmus > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
