stream == range ?

ketmar via Digitalmars-d digitalmars-d at puremagic.com
Sun May 31 13:09:01 PDT 2015


On Sun, 31 May 2015 11:44:03 -0400, Nick Sabalausky wrote:

> On 05/30/2015 07:06 AM, short2cave wrote:
>> Do the classic streams still make sense when we have Ranges ?
>>
>>
> I've been thinking the same thing lately. In fact, I'd been meaning to
> make a post regarding that.
> 
> Phobos's std.stream has been slated for an overhaul for awhile now, but
> it seems to me that ranges are already 90% of the way to BEING a total
> std.stream replacement:
> 
> Output Streams: AFAICT, 100% covered by output ranges. Output streams
> exist as a place for sticking arbitrary amounts of sequential data.
> Output range's "put" does exactly that.
> 
> Input Streams: Input ranges are very nearly a match for this. AFAICT,
> The only thing missing here is the ability to "read" not just the one
> "front" value, but to read the front N values as a chunk, without an
> O(n) sequence of front/popFront. So we'd just need another "optional"
> range characteristic: hasFrontN (or some such).

i wonder why people keep inventing new methods. there are `rawRead` in 
File, why don't simply reuse it?

second question is: why not build stream interface around "File 
abstraction", same as range, taking std.stdio.File as a base. and then 
simply add range wrappers to file entities.

i did that long time ago, and i'm very happy with the interface. and with 
ability to use std.stdio.File without any wrappers or phobos patches.

yet somehow i'm sure that this idea will be buried, and we'll got 
std.stdio.File as completely separate thing ("don't break the code" 
mantra), and "stream ranges" as separate thing, adding even more methods 
to already overloaded ranges.

/another useless rant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150531/128760ae/attachment.sig>


More information about the Digitalmars-d mailing list