Vote for std.process

Manu turkeyman at gmail.com
Thu Apr 11 23:24:57 PDT 2013


Sorry to derail the topic, but I'd just like to raise a major gripe I've
had with introducing anything into phobos recently.

I see this pattern where something is designed, discussed, and then voted
into phobos. At this time the design looks good on paper, but there is very
little practical experience using the library.
The problem then is, once accepted, people start using it, and at some
point some issues are found, or ideas for improvement are made based on
user experience, but the module can no longer be touched due to the general
phobia of making breaking changes...

Can I suggest that ALL new modules should be added to exp. rather than
std.? Here they will stay for at least 1 year, and while they live in exp,
it is understood that they are still in an experimental introductory phase.
Users who choose to use modules in exp are accepting that the API may
receive changes, and consequently, accepting the responsibility to update
their code (and not complain about it breaking their program), should the
library be amended in its introductory phase.
At some time later when the module has been used in a decent amount of
software, and the API has stabilised, it can then be moved to std. This
move is obviously a breaking change its self, but anyone who has agrees to
import exp modules has already accepted the responsibility to update their
code as such.

Thoughts?


On 12 April 2013 16:12, Nick Sabalausky <SeeWebsiteToContactMe at semitwist.com
> wrote:

> On Fri, 12 Apr 2013 06:46:51 +0200
> "Jesse Phillips" <Jessekphillips+d at gmail.com> wrote:
>
> > It is that time, If you would like to see the proposed
> > std.process include into Phobos please vote yes. If one condition
> > must be met specify under what condition, otherwise vote no.
> >
>
> Yes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130412/1d1c66f8/attachment-0001.html>


More information about the Digitalmars-d mailing list