State of mhash?

php.internals

Nikita Popov

6 years ago
Hi, I just noticed that the hash extension has a default-disabled --with-mhash 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 hash, and hash provides a compatibility layer for mhash. Should these functions be deprecated? Should this compatibility layer be kept indefinitely? Regards, Nikita

Christoph Becker

6 years ago
On 17.09.2019 at 16:25, Nikita Popov wrote: #
> I just noticed that the hash extension has a default-disabled --with-mhash > 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 hash, > 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>
-- Christoph M. Becker

Sara Golemon

6 years ago
On Wed, Sep 18, 2019 at 6:39 AM Christoph M. Becker <cmbecker69@gmx.de> wrote:
> > On 17.09.2019 at 16:25, Nikita Popov wrote: > > 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. >
Given that the mhash compatability shim is literally just "map this function and args to that function and args", this one feels like a no-brainer. Anyone who can't upgrade because of /this/ change can literally just drop a single (short) PHP script into their program to polyfill those APIs. It would be a kindness for someone to provide that, and if nobody else does I may just drop a package on composer in the new few months. +1 -Sara