Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82556
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ5L9iCbtU6P8=JD4_X9WN01bBspSteqSAzWe3vvn7hog@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>
Date: Fri, 13 Feb 2015 04:36:09 +0700
Message-ID: <CAEZPtU7BG+hBpRT-usg0gUruffw41YZq8qYjSuj_-mm4wXygnw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Andrey Andreev <narf@devilix.net>, Jordi Boggiano <j.boggiano@seld.be>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7
 ported SAPIs and extensions
From: pierre.php@gmail.com (Pierre Joye)

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.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org