Simen Kjaeraas wrote:
grauzone wrote:

void streamOut(T, R)(T object, R range)
{
    foreach(x; a) range.put(x);
    range.put(b);
    range.put(c);
}

So, um... what is a b c and T object?

In my opinion, this is a confusing example. I believe it was meant to be:

void streamOut(T, R)(T object, R range)
{
 foreach(x; object.a) range.put(x);
 range.put(object.b);
 range.put(object.c);
}

So, streamOut is a free function, which it normally would not be. Now, consider this:

struct foo {
 int[] a;
 bool b;
 char c;

 void streamOut(R)(R range) {
   foreach(x; a) range.put(x);
   range.put(b);
   range.put(c);
 }
}

I believe this is what you'd normally do.

Do note that I might have misinterpreted it all, as Andrei's code would not do what I have outlined above, I only feel it makes the most sense.

Yeah OK, but what about virtual functions? Not having it virtual is a real disadvantage, because subclass-parts aren't automatically dumped. What exactly is R, and why is it simpler than a Sink delegate? A Sink delegate is as simple as it gets, and what else than a string do you want to output? (Hint: this is probably not supposed to be a serialization framework.)

One thing that I could imagine that put() automatically takes care of formatting various data types into a string. Okay, where can I pass format specifiers? What if put() can't deal with the type? Or does it call std.string.format() anyway? Then why the indirection through the string? Why not call format() directly? (Yes, format() needs to be able to output using a sink instead of returning a string.)

Oh by the way, unlike a weird template, sink works with virtual methods, too.

I have the impression Andrei wants to cast everything into ranges instead of adhering to KISS.

--
 Simen

Reply via email to