On Sun, Oct 12, 2014 at 12:36 PM, Zeev Suraski <z...@zend.com> wrote:
> > For the record, I don't feel strongly about # comments, but I do think that > we should have good reasons to actually *remove* features that are better > than "this is how it's done". Valid reasons can be performance penalties of > keeping the feature, security issues, or potential significant reduction in > codebase complexity. I'm not sure whether # comments fall into any of these > buckets, but sounds like they don't. > > <broken_record>Each and every feature we break makes it a bit more difficult > to upgrade. The more difficult we make it - the more people are likely to > stick with old insecure versions, or visit alternative > options</broken_record> I have to agree with Zeev here, with one additional note. We have chosen to deprecate features, including ext/mysql. If we now decide not to remove some of them for 7, we may just remove the deprecation flag as we are going to support them for the next decade as well, whether we like it or not. >From the distros/pecl vs core, it is in my humble opinion, a non issue. Most of the major applications support alternative drivers now, including the most conservative ones like Wordpress (it is not badly meant, only a a statement about the situation). Distros tend to enable by default what the core provides or enables by default. PHP7 will be no different. Keeping it forever won't help. Removing it may not help as much as we wish but it will be a clear, loud and unambiguous signal, which is a good step forward. I also agree to have more options to vote on. Mass voting may hide something most of us won't notice. I also like to discuss what we do for the deprecated features we won't remove. Keeping the deprecated flags for the sake of keeping it sounds not so good. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
