Re: std.hash design

2012-06-25 Thread Regan Heath
On Fri, 22 Jun 2012 18:34:10 +0100, Johannes Pfau wrote: Am Fri, 22 Jun 2012 18:12:20 +0100 schrieb "Regan Heath" : Agreed. In fact I wouldn't bother with finishString either TBH, people can always pass the result of finish string into the method which produces the hex string representat

Re: std.hash design

2012-06-22 Thread Johannes Pfau
Am Fri, 22 Jun 2012 18:12:20 +0100 schrieb "Regan Heath" : > > Agreed. In fact I wouldn't bother with finishString either TBH, > people can always pass the result of finish string into the method > which produces the hex string representation. > > >In any case, we can probably have one static

Re: std.hash design

2012-06-22 Thread Regan Heath
On Fri, 22 Jun 2012 18:12:20 +0100, Regan Heath wrote: people can always pass the result of finish string into the method Aargh! "..people can always pass the result of finish STRAIGHT into the method.." -- Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: std.hash design

2012-06-22 Thread Regan Heath
On Fri, 22 Jun 2012 14:21:28 +0100, Johannes Pfau wrote: Am Fri, 22 Jun 2012 12:03:27 +0100 schrieb "Regan Heath" : It might help (or it might not) to have a glance at the "design" of the hashing routines in Tango: http://www.dsource.org/projects/tango/docs/current/ (see tango.util.digest et

Re: std.hash design

2012-06-22 Thread Johannes Pfau
Here's a first proposal for the API: http://dl.dropbox.com/u/24218791/d/src/digest.html One open question is: What should we do if a too small buffer is passed to the finish function (in the OOP API)? Should we check for the length only in debug(assert) or in debug+release mode (enforce) or shoul

Re: std.hash design

2012-06-22 Thread Johannes Pfau
Am Fri, 22 Jun 2012 12:03:27 +0100 schrieb "Regan Heath" : > > It might help (or it might not) to have a glance at the "design" of > the hashing routines in Tango: > http://www.dsource.org/projects/tango/docs/current/ > (see tango.util.digest etc) > > I contributed some of the initial code for t

Re: std.hash design

2012-06-22 Thread Regan Heath
On Fri, 22 Jun 2012 10:11:10 +0100, Johannes Pfau wrote: Pull request #221 and #585 both introduce modules for a new std.hash package. As those already change API compared to the old std.crc32 and std.md5 modules we should probably decide on a common interface for all std.hash modules. These

Re: std.hash design

2012-06-22 Thread Johannes Pfau
Am Fri, 22 Jun 2012 13:33:41 +0400 schrieb Dmitry Olshansky : > On 22-Jun-12 13:11, Johannes Pfau wrote: > > Pull request #221 and #585 both introduce modules for a new std.hash > > package. As those already change API compared to the old std.crc32 > > and std.md5 modules we should probably decide

Re: std.hash design

2012-06-22 Thread Dmitry Olshansky
On 22-Jun-12 13:11, Johannes Pfau wrote: Pull request #221 and #585 both introduce modules for a new std.hash package. As those already change API compared to the old std.crc32 and std.md5 modules we should probably decide on a common interface for all std.hash modules. These are the imho most i

std.hash design

2012-06-22 Thread Johannes Pfau
Pull request #221 and #585 both introduce modules for a new std.hash package. As those already change API compared to the old std.crc32 and std.md5 modules we should probably decide on a common interface for all std.hash modules. These are the imho most important questions: Free function (std.crc