DIP in making: ProtoObject

Jonathan M Davis newsgroup.d at jmdavisprog.com
Wed Apr 4 18:04:39 UTC 2018


On Wednesday, April 04, 2018 14:47:03 Luís Marques via Digitalmars-d wrote:
> Regarding the output range replacing toString. That's an obvious
> improvement. Yet, before that is set in stone, give the following
> at least some thought. I've always wondered about the use of
> output ranges. Yes, they can be more convenient to implement than
> input ranges, but they are less convenient to use because they
> are not composable (unless you create some kind of adapter Fiber
> that makes them input ranges). For instance, if you want to print
> an Object to the terminal with some color, you can't use a chain
> of ranges like `yourObject.toString.colorizer`, you have to
> output to some intermediary buffer. Just by coincidence,
> yesterday I was once again wondering about this and I decided to
> prototype an input-range-based formatter.  By restricting the
> initial version to a compile-time format string it actually made
> it *very* easy to implement a MVP. You basically just
> std.range.chain the first formatter item range and the remaining
> tail. And you can implement it piecemeal by using sformat to
> format integers/floats; this (temporarily) requires a small
> buffer in the range, but avoids the unbounded memory allocation
> for the stringy parts of the formatting (the literals, etc.),
> which is the truly problematic part.

In general, toString's API needs to work with functions like format and
to!string. If improvements need to be made to those functions, then they can
and should be, but in principle, by having ProtoObject, it's then possible
for a class to implement toString however it wants. It puts toString on
classes in pretty much the same boat that toString on structs is. The main
difference is that any classes derived from that class then needs to worry
about how their particular base class declared toString, and part of that
then is whether the function was declared as a virtual function or a
templated function. Now, declaring a useful toString that doesn't return
string gets a bit more entertaining with classes due to the fact that a
templated function isn't virtual, but each class hierarchy can then deal
with that in the best way for it rather than one particular solution being
pushed onto every class.

- Jonathan M Davis




More information about the Digitalmars-d mailing list