www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.parallelism: voting postponed

reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
A lot of suggestions have been made for std.parallelism in the last week 
of the review, and David currently doesn't have the time to fix all of 
them.  We will therefore postpone the voting, which was scheduled to 
begin on Friday 25 April, and restart the review process at a later date.

David, how much time do you need?

-Lars
Mar 20 2011
parent dsimcha <dsimcha yahoo.com> writes:
On 3/20/2011 9:24 AM, Lars T. Kyllingstad wrote:
 A lot of suggestions have been made for std.parallelism in the last week
 of the review, and David currently doesn't have the time to fix all of
 them.  We will therefore postpone the voting, which was scheduled to
 begin on Friday 25 April, and restart the review process at a later date.

 David, how much time do you need?

 -Lars
Given that a substantial amount of discussion is still going on (as opposed to me just having a fixed list of stuff to implement), maybe an extra 2 weeks. If we want to review something else in the mean time, it's ok if we put std.parallelism on hold slightly longer. Reviewers: I welcome your suggestions, even if they require design changes and require substantial effort to implement. However, if you're going to provide such non-trivial suggestions, though, please do so ASAP instead of at the last minute. This will allow time for the following important things that there wasn't enough time for with all the non-trivial suggestions I was getting at the last minute: 1. Discussion/refinement/clarification. The first time something is suggested, it's often vague, based on misunderstanding, etc. If something non-trivial is suggested well in advance, alternatives, refinements, clarifications, use cases, etc. can be discussed. If it's brought up at the last minute, I'm basically forced to either implement it immediately or dig my heels in against it immediately. This is obviously bad. 2. Proper thought about how to work any changes into the rest of the design. When something is implemented at the last minute, it tends to get bolted on instead of fit nicely into the design. 3. Implementation. Code that's written at the last minute tends not to be the most well-documented or bug-free.
Mar 20 2011