[phobos] Community shout-out?
SHOO
zan77137 at nifty.com
Sun Nov 14 00:05:07 PST 2010
I think that it is important that we prioritize our to-do list.
Therefore I think that firstly we should make a list. Next, it is
necessary for us to clarify the problem that each item has.
I show following list the thing which I hit on:
- std.stream, I/O (replace, enhance)
- std.xml (replace?)
- std.json (replace?)
- std.datetime (replace, enhance)
- scope/RAII (replace, enhance)
- std.scoket / asio (replace)
- std.event (enhance)
- std.serialize (enhance)
- documents (enhance)
- std.process (enhance)
- std.path, std.file (enhance)
- pure (apply)
- nothrow (apply)
- @safe/@trusted/@system (apply)
- shared (enhance, bug fix)
- GC (enhance)
- std.container (enhance)
- opDollars (enhance, apply)
- and some voted bugs (bug fix)
(I only enumerate of the list at this stage, and omit the detailed
explanation.)
Are there items else?
--
SHOO
(2010/11/14 14:52), Jonathan M Davis wrote:
> We have several modules in Phobos which are supposedly going to be deprecated in
> favor of better implementations (std.stream, std.xml, std.json, etc). As I
> understand it, this is primarily because the code isn't being maintained, is
> poorly designed for D2 (possibly because it isn't range-centric or just hasn't
> been updated with D2-only features), and/or lacks a maintainer/champion. In
> addition to that, there's various types of functionality which should probably
> be in Phobos but haven't been done yet.
>
> The Phobos developers only have so much time on their hands, and some portion of
> this kind of work is going to need to be done by people who are not currently on
> the Phobos team. That, and we seem to be adopting the idea that the ideal
> situation is for each module to have a "champion" of sorts who is behind the
> module, working to fix bugs on it and make it better.
>
> So, I was wondering if what we should do is figure out what some of the modules
> are that we want in Phobos - and in particular the ones currently in Phobos
> which need to be overhauled - and then post on the main D list looking for
> people willing to take them on. We don't want to a flood of code that needs to be
> reviewed for inclusion in Phobos, but if we want to get a lot of this stuff done,
> we need more people working on it - particularly people who are really looking
> to focus on it and champion it.
>
> So, I'm suggesting that we identify the top priority module which aren't likely
> to be done by Phobos developers any time soon and see if we can get others in
> the D community to do them. In particular, it's a problem that we have several
> modules which we intend to replace. The longer that we wait, the more code that
> will be written using the old modules, and the more code which will break when
> they get replaced.
>
> - Jonathan M Davis
More information about the phobos
mailing list