grauzone wrote:
Simen Kjaeraas wrote:
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.
Streaming out is a virtual function that takes a classic interface
object. (I explained that in two posts.)
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.)
It is simpler than a Sink delegate because the delegate is not simple;
it's simplistic. You can't use std.algorithm with a delegate, it only
accepts one type (meaning it is very inefficient if you have multiple
types to output) - it's essentially a non-design.
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.)
I'd spend more time on explaining that but I fear you want more to
convince yourself and others that output streams are no good and that
your non-design is simpler, than actually getting answers to your questions.
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.
I want to adhere to KISS, and therefore I want to support output ranges
with e.g. strings and files. If you don't take the time to look at
ranges as you yourself said, then why do you spend time commenting on
them? Shouldn't things go the other way?
Andrei
