Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82576
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.50 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEZPtU7BG+hBpRT-usg0gUruffw41YZq8qYjSuj_-mm4wXygnw@mail.gmail.com>
References: <bc6d032454578020cdd2cef172698534.squirrel@webmail.klapt.com>
 <54DB3184.8080408@seld.be> <CAPhkiZz+xY_W0fZRhaC1KXjPqqgfrMnvE1g=wrSq35bTuFuc8Q@mail.gmail.com>
 <CAGa2bXZ5L9iCbtU6P8=JD4_X9WN01bBspSteqSAzWe3vvn7hog@mail.gmail.com> <CAEZPtU7BG+hBpRT-usg0gUruffw41YZq8qYjSuj_-mm4wXygnw@mail.gmail.com>
Date: Fri, 13 Feb 2015 13:08:56 +0900
Message-ID: <CAGa2bXaoYuNfSKbe-TeeC01U8N0Dq1dAofysSUo=8+pSta8R1g@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Andrey Andreev <narf@devilix.net>, Jordi Boggiano <j.boggiano@seld.be>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c12f8c9afb60050ef06728
Subject: Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7
 ported SAPIs and extensions
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c12f8c9afb60050ef06728
Content-Type: text/plain; charset=UTF-8

Hi Pierre,

On Fri, Feb 13, 2015 at 6:36 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Fri, Feb 13, 2015 at 3:51 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi all,
> >
> > On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev <narf@devilix.net>
> wrote:
> >
> >> On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano <j.boggiano@seld.be>
> >> wrote:
> >> > On 09/02/2015 22:29, Anatol Belski wrote:
> >> >>
> >> >> ext/imap
> >> >> ext/mcrypt
> >> >> ext/pdo_dblib
> >> >
> >> >
> >> > Sorry if this was suggested already but if those are not maintained
> much
> >> and
> >> > should not be used further ideally, shouldn't we add E_DEPRECATED to
> >> them at
> >> > least?
> >> >
> >> > I understand that they are kept to avoid making the upgrade path
> harsher,
> >> > but it's also not great to let they linger on forever with no notice
> to
> >> > users that they are doing something wrong.
> >> >
> >>
> >> I don't think it has been suggested already, but I agree - should be
> >> deprecated.
> >
> >
> >
> > Vote is vote. Why don't we deprecate them by documentation with obvious
> > warning?
> > We cannot deprecate them immediately, anyway.
> >
> > Is there any objection for deprecation by document?
>
> So we do not want to kill them because they are still used (but dead).
> But we may come with some wrapper to replace almost all the features
> provided by the dead libs? At least for mcrypt, good luck to anyone
> willing to do that for imap ;). But now we should deprecate them but
> deprecation has lost its meaning as we vote on the actual removal,
> which may be rejected.
>
> So basically, unless we clearly have no chance to have a replacement,
> I am totally against adding yet some deprecation notices, not if
> adding a deprecation is actually followed by a removal, read: Vote for
> deprecation means removal in next. But if it is not the case and we
> keep deprecated features forever, then we may just kill the
> deprecation flag instead.


Isn't better to deprecate them in document than nothing?
That's what I thought for now.

I'm looking forward new crypt extension, BTW!
When it is available, we may have vote again.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c12f8c9afb60050ef06728--