DIP in making: ProtoObject

[Luís Marques]

On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei Alexandrescu 
wrote:
> I'm working on a simple older idea to get it out of the way in 
> preparation for the more difficult DIPs to come:
>
> https://github.com/andralex/DIPs/blob/ProtoObject/DIPs/DIPxxxx.md
>
> This is not officially reviewable yet, but conveys the gist and 
> could use some early feedback. Any insight will be appreciated.

I was going to propose exactly this approach to get rid of the 
monitor in my objects. It's a huge cache penalty that I have to 
pay (for no use, because I think monitors are an awful approach 
to multi-threading) just to get proper reference semantics and 
some other OO features. If we also get proper modernized objects 
that's a sweet, sweet cherry on top. Le cool! This is exactly the 
kind of house cleaning that will benefit D, and I hope to see 
more of. Very reassuring.

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.