The new std.process is ready for review

1100110 0b1100110 at gmail.com
Sun Feb 24 00:22:14 PST 2013


On 02/23/2013 09:07 PM, Jonathan M Davis wrote:
> On Saturday, February 23, 2013 18:58:28 H. S. Teoh wrote:
>> I suppose std.proc is out of the question? ;-)
>
> I don't know. Maybe.
>
>> I find this rather frustrating... sometimes it feels like Phobos is
>> suffering from premature standardization - we have a module with a
>> design that isn't very good, but just because it somehow got put into
>> Phobos, now it has to stick, no matter what. That's what we should do
>> *after* we have a good design, but at this point, the current
>> std.process clearly isn't ready to be cast in stone yet, yet we insist
>> it can't be changed (at least, not easily). So every little design
>> mistake that got overlooked in review and made it into Phobos becomes
>> stuck, even when the design is really only experimental to begin with.
>
> To some extent, I agree, but at the same time, we're taking forever to
> stabilize things, and unless we do, D will never take off, because no one will
> be able to rely on its API.
>
>> I think we should seriously consider the idea someone brought up in this
>> forum recently, of an experimental section of Phobos where new stuff is
>> put in, and subject to actual field-testing (as opposed to just toy test
>> cases when it was written), before it goes into Phobos proper.
>
> I definitely think that this should be considered. I think that it's often the
> case that the stuff that makes it into Phobos was either created specifically
> for Phobos (and didn't get much use ahead of time), or it's someone's personal
> module that they thought would be useful (in which case, it may have gotten
> heavy use from them but not by many people besides them). And freezing APIs
> before they've been field-tested means that we'll be permanently stuck with
> subpar APIs.
>
>> I really
>> do not want to see this problem repeated over and over, and we end up
>> with 15 modules with 2 or 3 appended to their name just because nothing
>> can be changed after it's put in. It really detracts from D's
>> presentability, esp. to outsiders and prospective new users, IMO.
>
> I honestly wouldn't expect many modules to be replaced outright. It's mostly
> just the older ones which risk that. But if ever have to do that with modules
> that went through the full review process, then we need to rethink how that's
> done. A propationary area for modules (where they're in Phobos but not in std
> yet) may very well help mitigate any such problems.
>
> - Jonathan M Davis

std.future.process;

and we've talked about it too much at this point. It will never be done.


More information about the Digitalmars-d mailing list