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

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

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.

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/

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/

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.

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/