Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104918
MIME-Version: 1.0
References: <CAJW__o1hA1DOp4Lf0LA2To5L-8c66+woFgoXAwfLaxxOiEwOPg@mail.gmail.com>
 <CAAfnsFXtzhEYSPNi-SGT9XeQRhNoS+Fe70ok6CjkOceyhMsEnw@mail.gmail.com>
In-Reply-To: <CAAfnsFXtzhEYSPNi-SGT9XeQRhNoS+Fe70ok6CjkOceyhMsEnw@mail.gmail.com>
Date: Sun, 24 Mar 2019 14:51:28 +0200
Message-ID: <CAJW__o2DZxYv+RoJO7R1xL9+fDhROdeBSK=W47Ybmfbr8xczOQ@mail.gmail.com>
To: Peter Kokot <peterkokot@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Unbundle ext/interbase
From: kalle@php.net (Kalle Sommer Nielsen)

Hi Peter

Den s=C3=B8n. 24. mar. 2019 kl. 14.39 skrev Peter Kokot <peterkokot@gmail.c=
om>:
> I'm all in for helping out here with both users using this and
> maintainers that need to worry about if this extension is even working
> ok. However, just one quick thought. The deprecation usually means
> that some functionality will cease to exist. And users usually expect
> and consider removing deprecated usage from their code and move to
> something else. Not that they will have an option to install it over
> PECL in PHP 8.0... Is this ok approach for this case? Because with
> this approach PHP is also saying quietly that PECL is a museum for
> extensions and not a place for developing them further. I might be
> completely wrong here though...

I opted for the deprecation warning as the functionality will
effectively cease to exist in php-src, we have done similar things to
other extensions (recently ext/wddx) or even ext/mysql (which did have
the ext/mysqli and ext/pdo_mysql) as alternatives, similar
ext/interbase have the ext/pdo_firebird alternative.

I see the following options to go about this extension:

1) Add a deprecation warning as the functionality will effective cease
to exist in php-src. We don't know if this extension will be taken
over if it ends up in PECL, so this is the safe bet, which is why I
opted for this initially in the RFC
2) Silently remove it already in 7.4, this is also a very viable
option, but it does not give the users to think about alternatives, We
did this for some extension in 5.6 -> 7.0, like ext/mssql. If we go
with this option, it means that there is no warnings and that whoever
picks up the extension (if any) can give them a warning free
environment.

I can amend the RFC to have these voting choices in mind if it is
preferable, similar to ext/wddx.

--=20
regards,

Kalle Sommer Nielsen
kalle@php.net