On 11/20/2011 12:30 PM, Jonas Drewsen wrote:
* Containers. (AFAIK noone is working on this. It's tough to get started
because, despite lots of discussion at various times on this forum,
noone seems to really know what they want. Since the containers in
question are well-known, it's much more a design problem than an
implementation problem.)
>
* Allocators. (I think Phobos desperately needs a segmented stack/region
based allocator and I've written one. I've also tried to define a
generic allocator API, mostly following Andrei's suggestions, but I'll
admit that I didn't really know what I was doing for the general API.
Andrei has suggested that allocators should have real-world testing on
containers before being included in Phobos. Therefore, containers block
allocators and if the same person doesn't write both, there will be a
lot of communication overhead to make sure the designs are in sync.)
I've though about doing some containers myself but have hesitated since
the general opinion seem to be that allocators need to be in place first.
Yeah, this is problematic. In voting against my allocator proposal,
Andrei mentioned that he wanted the allocators to be well-tested in the
container API first. This means either we have a circular dependency or
allocators and containers need to be co-developed. Co-developing them
is problematic. If one person does containers and another allocators,
the project might be overwhelmed by communication overhead. If the same
person does both, then this is asking a pretty lot for a hobby project.
Of course, I hope to graduate in <1 year and will be looking for a job
when I do. Any company out there have a strategic interest in D and
want to hire me to work full-time on allocators and containers?
* Streams. (Another item where the bottleneck is mostly at the design
level and people not really knowing what they want.)
What does streams provide that could not be provided by ranges?
If I understand correctly, streams _would_ be a flavor of ranges. They
would just be ranges that are geared towards being stacked on top of one
another specifically for the purpose of I/O. They would typically be
design around the vanilla input range (not forward, random access, etc.)
or output ranges.
Traditionally, streams would also be class based instead of template
based. However, IMHO a good case can be made for template based stream
ranges in D because we have std.range.inputRangeObject and
std.range.outputRangeObject. This means that you can stack streams
using templates, with no virtual function call overhead, and then if you
need to respect some binary interface you could just stack an
inputRangeObject() or outputRangeObject() on top of all your other crap
and only have one virtual call. Example:
auto lines = lineReader(
gzipUncompresser(
rawFile("foo.gz")
)
);
// LineReader!(GzipUncompresser!(RawFile)))
pragma(msg, typeof(lines));
auto objectOriented = inputRangeObject(lines);
// InputRangeObject!(char[])
pragma(msg, typeof(objectOriented));
