Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77912
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3832FC29-CE4E-49C8-B9F1-3797F019D9F8@lerdorf.com>
References: <CAF+90c-B74M82xOkT1VguqShE3b2W2YLJ1HX_XzCJtG_WUSxxg@mail.gmail.com>
	<CAKOpQSwgpU+T+W_5q+uftWzhtH8mvrqhidRArdfKP9fCYE1W5A@mail.gmail.com>
	<3832FC29-CE4E-49C8-B9F1-3797F019D9F8@lerdorf.com>
Date: Mon, 13 Oct 2014 14:29:06 +0400
Message-ID: <CA+9eiLsVSmuCVboXhZBeVXBiTYt1QCCgMfFH19-fWREw=iZDYA@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Kris Craig <kris.craig@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3441805687b005054b5ebc
Subject: Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
From: dmitry@zend.com (Dmitry Stogov)

--047d7b3441805687b005054b5ebc
Content-Type: text/plain; charset=UTF-8

Note, that once we move extension outside of main source tree, only
extension maintainers (if any) will support them.

According to the voting process, I think it makes sense to vote for each
feature separately.

Thanks. Dmitry.




On Sun, Oct 12, 2014 at 4:13 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> > On Oct 11, 2014, at 16:47, Kris Craig <kris.craig@gmail.com> wrote:
> >
> >> On Oct 11, 2014 1:52 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote:
> >>
> >> Hi internals!
> >>
> >> We currently have a number of deprecated features, which we likely want
> to
> >> remove in PHP 7. I've created a tracking RFC listing deprecated
> >> functionality (if I missed something, please tell):
> >>
> >>    https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
> >>
> >> I expect many of these are no-brainers (like assigning new
> by-reference),
> >> but other items like removal of ext/mysql may need additional
> > consideration.
> >>
> >> Unless there are items that are particularly contested, I'd like to
> handle
> >> the bulk of these in a single vote and only have separate votes for
> >> ext/ereg and ext/mysql, as these are arguably more intrusive.
> >>
> >> Thanks,
> >> Nikita
> >
> > +1 on all of that.
> >
> > As far as ext/mysql is concerned, I would eagerly vote in favor of
> removing
> > it.  It performs poorly, is procedural, less secure, doesn't support
> > prepared statements, etc.
> >
> > It's always annoyed me how sites like w3schools still teach people to use
> > ext/mysql.  It's been deprecated for quite awhile now and I think it's
> time
> > to pull the plug on it.
>
> Keep in mind though that it would be mostly symbolic. The majority of
> users get their PHP and extensions from distros. And distros have been
> separating out core-bundled extensions for a decade now. Users have
> absolutely no idea whether their php-mysql package comes from core or from
> pecl, nor do they care. So, unbundling it on our side will have close to
> zero impact on its use. In fact, in a weird way it might actually help make
> people continue to use it because if we unbundle it and stick it in pecl we
> would obviously not have it spew out 'deprecated' notices like we do as of
> 5.5. I mean, we still could, of course, but it would be weird having a
> non-core pecl extension declare itself deprecated.
>
> I am not against unbundling it, I just don't think it will achieve what
> you hope it will.
>
> -Rasmus
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7b3441805687b005054b5ebc--