[RFC] I/O and Buffer Range
Joseph Cassman
jc7919 at outlook.com
Mon Dec 30 23:30:21 PST 2013
On Tuesday, 31 December 2013 at 01:51:23 UTC, Brad Anderson wrote:
> On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky
> wrote:
>> Proposal
>
> Having never written any parser I'm not really qualified to
> seriously give comments or review it but it all looks very nice
> to me.
>
> Speaking as just an end user of these things whenever I use
> ranges over files or from, say, std.net.curl the byLine/byChunk
> interface always feels terribly awkward to use which often
> leads to me just giving up and loading the entire file/resource
> into an array. It's the boundaries that I stumble over. byLine
> never fits when I want to extract something multiline but
> byChunk doesn't fit because I often if what I'm searching for
> lands on the boundary I'll miss it.
>
> Being able to just do a matchAll() on a file, std.net.curl,
> etc. without sacrificing performance and memory would be such a
> massive gain for usability.
>
> Just a simple example of where I couldn't figure out how to
> utilize either byLine or byChunk without adding some clunky
> homegrown buffering solution. This is code that scrapes website
> titles from the pages of URLs in IRC messages.
>
> [...]
>
> If I'm understanding your proposal correctly that get(url)
> could be replaced with a hypothetical std.net.curl "buffer
> range" and that could be passed directly to matchFirst. It
> would only take up, at most, the size of the buffer in memory
> (which could grow if the capture grows to be larger than the
> buffer) and wouldn't read the unneeded portion of the resource
> at all. That would be such a huge win for everyone so I'm very
> excited about this proposal. It addresses all of my current
> problems.
>
> [...]
I find the same to be the case with API's used to process files.
It would be a real win to have a simple, efficient, and possibly
non-blocking range interface over a file able to access a single
byte or character at a time.
I remember a discussion on this forum that spoke positively about
the async and await combination of keywords in .NET 4.5. If
asynchronous and synchronous functionality could be combined with
a flexible buffer in a UFCS call chain I think that would hit a
sweet spot for code composability and understandability.
Joseph
More information about the Digitalmars-d
mailing list