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.
