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. > > > Well, there's a difference between taking advantage of newer features, and > being compatible with newer versions. Wordpress runs on 5.4. Just because > the project doesn't use namespaces or short array syntax doesn't mean that > it won't run on it. > We're not discussing introducing new features here. We're discussing the deprecation of old features. > So there's a huge difference between compatible with and adopted fully. For > some projects it may never make sense to use newer features. And that's > fine, there's NOTHING wrong with that. But we shouldn't use those as > examples that we can ignore them when it comes to future planning... > How are we ignoring anything in future planning by giving people what could potentially be several years before the extension is removed. In the mean time, we have E_DEPRECATED errors being thrown (again in PHP 5.5, which likely 95% of those CMS frameworks you mention that depend on ext/mysql won't ever upgrade to), and the necessary migration guide and warnings in the manual. We're leading people into a sane migration path that will never happen if all we do is confuse them by saying one thing in the manual and doing nothing in the code. Most people will probably just take that as a sign of "nothing has changed... just keep doing whatever you're doing" I'd rather see those warnings and have the information in the manual and urge those projects to start finding a suitable migration path for the next year or two than spend a year convincing myself that people will do anything about ext/mysql code just because we're telling them its deprecated in the manual. I think you greatly under-estimate who reads the manual and who has the power to modify/affect these OSS frameworks/CMSs to move away from ext/mysql. Only when they have tens of thousands of users breathing down their upstream's neck about getting warnings will there be some justifiable stake for those upstreams to start taking serious action. I believe the most popular ones like WP have already demonstrated they are heading in that direction now. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
