www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.stream's toString and toHash, and the module "crc32"

reply Ben Hinkle <bhinkle4 juno.com> writes:
hi,
I'd like to change the behavior of std.stream.Stream's toString and toHash.
Right now toString gets all the stream contents into a char[] and returns
that. I think it should keep Object's toString. Similarly toHash right now
gets all the content and calls crc32 and I think it should just use
Object's toHash. The current behavior of reading the entire stream contents
into a char[] doesn't need a special function. Such behavior is rare enough
and simple enough (and wierd enough) that users can do that themselves.

On a related note I'd like to propose removing the module src/phobos/crc32.d
since the same functionality is in std.zlib in the function crc32. The only
place in std that the top-level crc32 is used is in Stream's toHash.

thoughts?
-Ben
Aug 28 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
hi,
I'd like to change the behavior of std.stream.Stream's toString and toHash.
Right now toString gets all the stream contents into a char[] and returns
that. I think it should keep Object's toString. Similarly toHash right now
gets all the content and calls crc32 and I think it should just use
Object's toHash. The current behavior of reading the entire stream contents
into a char[] doesn't need a special function. Such behavior is rare enough
and simple enough (and wierd enough) that users can do that themselves.

Definately. Calling these functions on a stream should really not return stream data by default.
On a related note I'd like to propose removing the module src/phobos/crc32.d
since the same functionality is in std.zlib in the function crc32. The only
place in std that the top-level crc32 is used is in Stream's toHash.

Duplication of code seems silly, but I do like having crc32 as a standalone function. I don't suppose it would make sense to have zlib import std.crc32? Sean
Aug 28 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
hi,
I'd like to change the behavior of std.stream.Stream's toString and
toHash. Right now toString gets all the stream contents into a char[] and
returns that. I think it should keep Object's toString. Similarly toHash
right now gets all the content and calls crc32 and I think it should just
use Object's toHash. The current behavior of reading the entire stream
contents into a char[] doesn't need a special function. Such behavior is
rare enough and simple enough (and wierd enough) that users can do that
themselves.

Definately. Calling these functions on a stream should really not return stream data by default.
On a related note I'd like to propose removing the module
src/phobos/crc32.d since the same functionality is in std.zlib in the
function crc32. The only place in std that the top-level crc32 is used is
in Stream's toHash.

Duplication of code seems silly, but I do like having crc32 as a standalone function. I don't suppose it would make sense to have zlib import std.crc32?

The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in std.zlib is standalone in the sense that it you can just call it with a bufer eithout worrying about anything else. The signature is uint crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't even called std.crc32 - the module name is just plain old crc32) involves several functions: uint init_crc32(); uint update_crc32(ubyte val, uint crc); uint update_crc32(char val, uint crc); uint strcrc32(char[] s); So to use crc32.d you have to loop over the buffer yourself and call update_crc32 and to use std.zlib.crc32 you just pass it an initial value (0 for the initial crc32 call) and the buffer. The API in std.zlib.crc32 is better IMO.
Aug 28 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sat, 28 Aug 2004 16:31:54 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and
 toHash. Right now toString gets all the stream contents into a char[] 
 and
 returns that. I think it should keep Object's toString. Similarly 
 toHash
 right now gets all the content and calls crc32 and I think it should 
 just
 use Object's toHash. The current behavior of reading the entire stream
 contents into a char[] doesn't need a special function. Such behavior 
 is
 rare enough and simple enough (and wierd enough) that users can do that
 themselves.

Definately. Calling these functions on a stream should really not return stream data by default.
 On a related note I'd like to propose removing the module
 src/phobos/crc32.d since the same functionality is in std.zlib in the
 function crc32. The only place in std that the top-level crc32 is used 
 is
 in Stream's toHash.

Duplication of code seems silly, but I do like having crc32 as a standalone function. I don't suppose it would make sense to have zlib import std.crc32?

The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in std.zlib is standalone in the sense that it you can just call it with a bufer eithout worrying about anything else. The signature is uint crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't even called std.crc32 - the module name is just plain old crc32) involves several functions: uint init_crc32(); uint update_crc32(ubyte val, uint crc); uint update_crc32(char val, uint crc); uint strcrc32(char[] s); So to use crc32.d you have to loop over the buffer yourself and call update_crc32 and to use std.zlib.crc32 you just pass it an initial value (0 for the initial crc32 call) and the buffer. The API in std.zlib.crc32 is better IMO.

But the API shown above is more like the sort of API used for md4, md5, sha0, sha1, etc.. I would ideally like to see: crc32_start(); <- starts the caclulation. crc32_update(); <- updates the crc with more data. crc32_finish(); <- concludes the crc. to allow piece by piece calculation, and one function i.e. crc32(); <- calls the 3 methods above. to do it all in one step. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 29 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Regan Heath wrote:

 On Sat, 28 Aug 2004 16:31:54 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and
 toHash. Right now toString gets all the stream contents into a char[]
 and
 returns that. I think it should keep Object's toString. Similarly
 toHash
 right now gets all the content and calls crc32 and I think it should
 just
 use Object's toHash. The current behavior of reading the entire stream
 contents into a char[] doesn't need a special function. Such behavior
 is
 rare enough and simple enough (and wierd enough) that users can do that
 themselves.

Definately. Calling these functions on a stream should really not return stream data by default.
 On a related note I'd like to propose removing the module
 src/phobos/crc32.d since the same functionality is in std.zlib in the
 function crc32. The only place in std that the top-level crc32 is used
 is
 in Stream's toHash.

Duplication of code seems silly, but I do like having crc32 as a standalone function. I don't suppose it would make sense to have zlib import std.crc32?

The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in std.zlib is standalone in the sense that it you can just call it with a bufer eithout worrying about anything else. The signature is uint crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't even called std.crc32 - the module name is just plain old crc32) involves several functions: uint init_crc32(); uint update_crc32(ubyte val, uint crc); uint update_crc32(char val, uint crc); uint strcrc32(char[] s); So to use crc32.d you have to loop over the buffer yourself and call update_crc32 and to use std.zlib.crc32 you just pass it an initial value (0 for the initial crc32 call) and the buffer. The API in std.zlib.crc32 is better IMO.

But the API shown above is more like the sort of API used for md4, md5, sha0, sha1, etc.. I would ideally like to see: crc32_start(); <- starts the caclulation. crc32_update(); <- updates the crc with more data. crc32_finish(); <- concludes the crc. to allow piece by piece calculation, and one function i.e. crc32(); <- calls the 3 methods above. to do it all in one step. Regan

The difference is that the crc algorithm doesn't need any state (I think). So crc_start just returns some initial value like 0 or -1 (which could be the default value of an update function in case people don't want to think about it) and finish is a no-op. The only non-trivial function is the update. The md5 algorithms have non-trivial start and finish. But then I haven't used crc or md5 so I'm not going to push any particular API - I'm just stating my position as an outsider to the whole thing.
Aug 29 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Sun, 29 Aug 2004 21:57:17 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Regan Heath wrote:

 On Sat, 28 Aug 2004 16:31:54 -0400, Ben Hinkle <bhinkle4 juno.com> 
 wrote:
 Sean Kelly wrote:

 In article <cgql5a$2qt$1 digitaldaemon.com>, Ben Hinkle says...
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and
 toHash. Right now toString gets all the stream contents into a char[]
 and
 returns that. I think it should keep Object's toString. Similarly
 toHash
 right now gets all the content and calls crc32 and I think it should
 just
 use Object's toHash. The current behavior of reading the entire 
 stream
 contents into a char[] doesn't need a special function. Such behavior
 is
 rare enough and simple enough (and wierd enough) that users can do 
 that
 themselves.

Definately. Calling these functions on a stream should really not return stream data by default.
 On a related note I'd like to propose removing the module
 src/phobos/crc32.d since the same functionality is in std.zlib in the
 function crc32. The only place in std that the top-level crc32 is 
 used
 is
 in Stream's toHash.

Duplication of code seems silly, but I do like having crc32 as a standalone function. I don't suppose it would make sense to have zlib import std.crc32?

The std.zlib calls the crc32 code in etc.c.zlib. The crc32 function in std.zlib is standalone in the sense that it you can just call it with a bufer eithout worrying about anything else. The signature is uint crc32(uint crc,void[] buf). The signature in crc32.d (note crc32 isn't even called std.crc32 - the module name is just plain old crc32) involves several functions: uint init_crc32(); uint update_crc32(ubyte val, uint crc); uint update_crc32(char val, uint crc); uint strcrc32(char[] s); So to use crc32.d you have to loop over the buffer yourself and call update_crc32 and to use std.zlib.crc32 you just pass it an initial value (0 for the initial crc32 call) and the buffer. The API in std.zlib.crc32 is better IMO.

But the API shown above is more like the sort of API used for md4, md5, sha0, sha1, etc.. I would ideally like to see: crc32_start(); <- starts the caclulation. crc32_update(); <- updates the crc with more data. crc32_finish(); <- concludes the crc. to allow piece by piece calculation, and one function i.e. crc32(); <- calls the 3 methods above. to do it all in one step. Regan

The difference is that the crc algorithm doesn't need any state (I think).

The state is the CRC itself. It's similar to md5, md5's state is an array of ubytes and a length the state array is represented as characters to give the fingerprint.
 So crc_start just returns some initial value like 0 or -1 (which could be
 the default value of an update function in case people don't want to 
 think about it) and finish is a no-op. The only non-trivial function is 
 the
 update.

 The md5 algorithms have non-trivial start and finish. But then I
 haven't used crc or md5 so I'm not going to push any particular API - I'm
 just stating my position as an outsider to the whole thing.

My position is that it would be consistent if similar operations had similar interfaces, I think a CRC is a simple type of data fingerprint, so it belongs in the same family as md5 etc and should therefore have a similar interface. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 29 2004
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
Ben Hinkle wrote:
 hi,
 I'd like to change the behavior of std.stream.Stream's toString and toHash.
 Right now toString gets all the stream contents into a char[] and returns
 that. I think it should keep Object's toString. Similarly toHash right now
 gets all the content and calls crc32 and I think it should just use
 Object's toHash. The current behavior of reading the entire stream contents
 into a char[] doesn't need a special function. Such behavior is rare enough
 and simple enough (and wierd enough) that users can do that themselves.

I think I agree, but it's far enough above my head that I probably shouldn't comment. ;)
 On a related note I'd like to propose removing the module src/phobos/crc32.d
 since the same functionality is in std.zlib in the function crc32. The only
 place in std that the top-level crc32 is used is in Stream's toHash.

I definitely can't understand why it has to be in the root of phobos (and why is object.d in the root, too?) And why are there multiple crc32 functions? I can't explain that either. Also, (and now I'm off-topic) I don't think phobos should depend on anything in "etc". If it's needed by phobos, it should be moved it to an obscure corner of "std".
 
 thoughts?

You bring up some good points. There some many things in phobos that are messy and don't seem to make sense. That's why we're finding plenty of things to discuss in the "Phobos Rising" forum (http://www.dsource.org/forums/viewforum.php?f=31)
 -Ben

-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Aug 28 2004