On 12-Aug-12 03:29, Andrei Alexandrescu wrote:
> N.B. I haven't yet reviewed the proposal.
>
> There's been a lot of discussion about the behavior of hash
> accumulators, and I've just have a chat with Walter about such.
>
> There are two angles in the discussion:
>
> 1. One is, the hash accumulator should work as an operand in an
> accumulation expression. Then the reduce() algorithm can be used as
> follows:
>
> HashAccumulator ha;
> reduce!((a, b) => a + b)(ha, [1, 2, 3]);
> writeln(ha.finish());
>
> This assumes the hash overloads operator +.

Would have been nice to have operator '<-'  for "place" *LOL* :)
(OT: I think C++ would be a much better place if it had it for e.g. iostream ...)

>
> I think we should reify the notion of finish() as an optional method for
> output ranges. We define in std.range a free finish(r) function that
> does nothing if r does not define a finish() method, and invokes the
> method if r does define it.
>
> Then people can call r.finish() for all output ranges no problem.
>
> For files, finish() should close the file (or at least flush it -
> unclear on that).

Easy to check:
{
  File f = File("myfile", "w");
  auto sink = f.lockingTextWriter;
  dumpTo(sink, some_vars);
  dumpTo(sink, some_other_vars);
  sink.finish(); //would be taking on f's job to close file
  return f; //and now what? clearly f is the one responsible
// (with the means to transfer that responsibility)
}

So IMO ranges should not step down to topology & origins of data be it output range or input range. This also means that with streams, finish is a flush and thus I'd expect finish to be callable many times in row.


>
> Destroy!

One thing I don't like about it is a by-hand nature of it. Manual way is good only when you are interested in the result of finish.

I half expect to see rule #X of D coding standard:

use RAI or scope(exit) to flush an output range

-- 
Dmitry Olshansky

On Sat, Aug 11, 2012 at 4:29 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> For files, finish() should close the file (or at least flush it - unclear on
> that). I also wonder whether there exists a better name than finish(), and
> how to handle cases in which e.g. you finish() an output range and then you
> put more stuff into it, or you finish() a range several times, etc.
>

As another data point, std.log has a Logger interface which defines
log(...) and flush (...) so this fits perfectly into this output range
design. Here are the current signatures:

shared void log(const ref LogMessage message);
shared void flush();

finish would be a weird name for 'interface Logger' because it is not a final operation. For what it is worth, Java's OutputStream has the following:

void write(...) // overloaded three times
void flush() // "Flushes this output stream and forces any buffered
output bytes to be written out."
void close() // "Closes this output stream and releases any system
resources associated with this stream."

On 12/08/12 00:29, Andrei Alexandrescu wrote:
> I think we should reify the notion of finish() as an optional method for output
> ranges. We define in std.range a free finish(r) function that does nothing if r
> does not define a finish() method, and invokes the method if r does define it.
>
> Then people can call r.finish() for all output ranges no problem.

What about a start() method?  You may recall in the RandomSample revisions I had to introduce a tweak to ensure that the first value returned by front() was set only the first time front() was called, and not in the constructor.

The idea of the start() method would be to addresses this requirement, i.e. to do something immediately before front() gets called for the first time and not earlier.

On Saturday, 11 August 2012 at 23:29:57 UTC, Andrei Alexandrescu wrote:
> This assumes the hash overloads operator +.

Wouldn't "~" be a better choice?

On 13/08/12 01:08, Joseph Rushton Wakeling wrote:
> What about a start() method?

Was this a daft question? :-)

On 8/15/12 6:27 AM, Mehrdad wrote:
> On Saturday, 11 August 2012 at 23:29:57 UTC, Andrei Alexandrescu wrote:
>> This assumes the hash overloads operator +.
>
> Wouldn't "~" be a better choice?

I think neither would be a good choice.

Andrei