Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107201
To: Nikita Popov <nikita.ppv@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAF+90c_WAXV1zC9XaF9vL6JVuscibrUR3+Jb6t2_ZEb7Exy8MA@mail.gmail.com>
Message-ID: <c0a08e3a-cb0e-3adf-6b18-878bb13e2bad@gmx.de>
Date: Wed, 18 Sep 2019 13:39:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c_WAXV1zC9XaF9vL6JVuscibrUR3+Jb6t2_ZEb7Exy8MA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: State of mhash?
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 17.09.2019 at 16:25, Nikita Popov wrote:
#
> I just noticed that the hash extension has a default-disabled --with-mha=
sh
> option, that enables a couple of additional mhash_* functions. From what=
 I
> was able to gather, mhash was an old extension that was superseded by ha=
sh,
> and hash provides a compatibility layer for mhash.
>
> Should these functions be deprecated? Should this compatibility layer be
> kept indefinitely?

The documentation[1] states for more than ten years now:

| This extension is obsoleted by Hash.

So I think actually deprecating these functions for PHP 8 is appropriate.

[1] <https://www.php.net/manual/en/intro.mhash.php>

=2D-
Christoph M. Becker