On Fri, 27 Jun 2008, Scott MacVicar wrote: > Pierre Joye wrote: > > On Mon, Jun 2, 2008 at 12:34 PM, Scott MacVicar <[EMAIL PROTECTED]> wrote: > > > Pierre Joye wrote: > > > > On Mon, Jun 2, 2008 at 10:21 AM, Derick Rethans <[EMAIL PROTECTED]> > > > > wrote: > > > > > On Mon, 2 Jun 2008, Pierre Joye wrote: > > > > > > > > > > > While working on the windows ports, I asked Sara about the mhash > > > > > > status in regard of the new shiny ext/hash. The plan is to remove > > > > > > ext/hash completely and emulate it in ext/hash to keep the BC. It > > > > > > could even a configuration flag if one likes to be sure to clean his > > > > > > code to use only the hash APIs. > > > > > The mhash extension features some more versions of some algorithms: > > > > > http://mhash.sourceforge.net/ But why bother changing it? > > > > Which algo(s) (or algo version) is not supported by ext/hash? I did > > > > not spot one after a quick read. > > > > > > > sha192 and sha224 > > > snefru128 > > > md2 > > > > > > > > I've not heard of any issues about ext/mhash. > > > > My main reasons would be to do not have to maintain ext/mhash and the > > > > libmhash Windows port. > > > > > > > > Cheers, > > > I'm happy to see us removing a dependency, especially if it makes thigns > > > easier to build on Windows. > > > > In case someone likes to do it, Scott has volunteered and has already > > added some of the missing algo in hash. He will also add the BC layer. > > ext/mhash now wraps around ext/hash in 5.3 > > I'd like to recommend we add a E_DEPRECATED to anything mhash_* related and > drop the extension for 6?
Why? The idea of this was not to get rid of mhash, it was to prevent the dependency on a library. I don't think we should just start getting rid of mhash. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
