Proposal for std.path replacement
Jonathan M Davis
jmdavisProg at gmx.com
Sun Mar 6 19:12:59 PST 2011
On Sunday 06 March 2011 18:08:49 Andrei Alexandrescu wrote:
> Yah, thing is people work on stuff they care about, not the most urgent
> stuff - surprise! :o) As such we don't have a ton of proposals for
> networking and xml, but we do have one (and I won't argue it's a bad
> one) for rehashing a module that basically worked.
And it doesn't help that the people who may need a particular module aren't
necessarily the same folks with the time and know-how to actually implement
it...
In any case, I think that it's safe to say that we can go forward with a "one
review at a time" policy for now and revisit it if it ever becomes a problem.
While I don't like the fact that std.path will be delayed, the occasional delay
of a single module likely isn't a big deal. If we actually start get enough
modules proposed for review that we actually get a bit of a queue going, _then_
it could be a problem. But until that happens, there isn't really much sense in
worrying about it.
I _was_ thinking of putting forward a new proposal which includes the unit
testing functionality that assertPred had which won't end up in an improved
assert, so having to wait for both std.parallelism and std.path to be fully
reviewed is bit annoying, but it's not exactly urgent. It can wait if it has to.
But both that and std.path may be able to have shorter review cycles than more
complex proposals, simply because they're not as complex. Stuff like
std.parallelism needs a thorough review. Stuff like std.path needs to be well-
reviewed, but it doesn't really need as thorough a review, since it's much
simpler functionality. So, if we end up with several smaller items for review,
we may be able to move through those faster than several large ones anyway, and
large ones are likely to be rarer simply due to the amount of work involved.
In any case, we can go forward as you suggest with the "one review at time"
policy and work with that if and until it becomes a problem.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list