Phobos Wish List/Next in Review Queue?

Jonas Drewsen jdrewsen at nospam.com
Sun Nov 20 09:30:48 PST 2011


Den 20-11-2011 04:02, dsimcha skrev:
> Now that we've got a lot of contributors to Phobos and many projects in
> the works, I decided to start a thread to help us make a rough plan for
> Phobos's short-to-medium term development. There are three goals here:
>
> 1. Determine what's next in the review queue after std.csv (voting on
> std.csv ends tonight, so **please vote**).
>
> 2. Come up with a wish list of high-priority modules that Phobos is
> missing that would make D a substantially more attractive language than
> it is now.
>
> 3. Figure out who's already working on what from the wish list and what
> bottlenecks, if any, are getting in the way and what can be done about
> them.
>
> The following is the wish list as I see it. Please suggest additions and
> correct any errors, as this is mostly off the top of my head. Also,
> status updates if you're working on any of these and anything
> substantial has changed would be appreciated.
>
> * Some higher level networking support, such as HTTP, FTP, etc. (Jonas
> Drewsen's CURL wrapper handles a lot of this and may be ready for a
> second round of review.)

As I've mentioned in another thread it is ready for a second round of 
review. We just need someone to step up and run the review since it 
wouldn't be apropriate for me to do it myself. Anyone?

> * Serialization. (Jacob Carolberg's Orange library might be a good
> candidate. IIRC he said it's close to ready for review.)
>
> * Encryption and hashing. (This is more an implementation problem than a
> design problem and AFAIK noone is working on it.)
>
> * 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.

> * 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?

/Jonas



More information about the Digitalmars-d mailing list