Andrei Alexandrescu wrote:
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.)
There were a lot of posts in this thread. From what I've gathered, what
you said wasn't really concrete. Not as concrete as the sink proposals.
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.
At some point, you need to format it to a string anyway. And it's
probably not favorable to move that code into some deeply buried library
code, because then you don't have full control over formatting. Anyway,
I don't quite understand what you want to do. We were talking abou
improving toString, right?
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.
It's not my design, and I didn't even come up with that proposal. Come
on, I know my tone and my posts is bitchy as hell, but flaming is not
really what I'm up to.
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?
Oh, I look at the Phobos docs as it seems necessary. But I still might
not know to the fullest how the pieces fit together and so on.
Andrei
