Difference between revisions of "DIP73"
(Link updated) |
(Minor updates) |
||
Line 92: | Line 92: | ||
;Proposal implementation steps: | ;Proposal implementation steps: | ||
− | # Create | + | # Create an experimental library project at Github and verify the outcome |
− | |||
− | |||
− | |||
Note: New changes doesn't force current developers to perform any additional activities on their side | Note: New changes doesn't force current developers to perform any additional activities on their side | ||
Line 112: | Line 109: | ||
* out of the box readiness (Curiosity is available in installation process of DMD package, no compilation errors etc.) | * out of the box readiness (Curiosity is available in installation process of DMD package, no compilation errors etc.) | ||
* wide range of community members involved in the development to reduce controversy and fragmentation staring from the initial stage (development can't be hidden) | * wide range of community members involved in the development to reduce controversy and fragmentation staring from the initial stage (development can't be hidden) | ||
+ | * no dependency hell | ||
The code.dlang.org packages' status will remain unchanged. They can be used as a special purpose packages without a need of standardization burden. | The code.dlang.org packages' status will remain unchanged. They can be used as a special purpose packages without a need of standardization burden. |
Latest revision as of 18:38, 6 March 2015
Title: | D Drafting Library |
---|---|
DIP: | 73 |
Version: | 1 |
Status: | Draft |
Created: | 2015-02-04 |
Last Modified: | 2015-03-6 |
Author: | Piotr Poltorak |
Links: | — NG announcement and discussion |
Contents
Abstract
D Drafting Library is an official library modeled by the D community and designed to support the development process of the D Standard Library. The drafting library is coupled with the standard library and doesn't introduce any duplicated functionality. It should be used during the drafting stage of the new functionality development.
Rationale
Without appropriate process it's hard to keep standard library stable while adding new features at the same time.
Submitting new functionality to standard library has a high entry barrier. A new functionality should provide complete implementation and documentation. It is also obligated to fulfill demanding requirements allowing wide adoption. Doing all work at one time can be challenging even for the best software engineers.
Some comments regarding the complexity of the potential Phobos modules can be found here: Wish list of new modules
The drafting library doesn't prefer the stability over a progress. Backward compatibility is reserved for the standard library.
Description
Standardization process can be divided into several stages. The ISO/IEC implementation can be checked as an example:
http://www.iec.ch/standardsdev/how/processes/development/
Current status
To add new functionality to the standard library it is required to create a pull requested as described here:
Get involved wiki Pull Requests wiki
The process of delivering a new submission can be visualized in the following way:
The recently added std.experimental module is supposed to allow a more flexible development of new modules in the standard library.
However there are several problems with this solution:
- it is not clear how much the quality requirement for new submission should be decreased
- standard library can be polluted with many not finished modules
- development and maintenance of Phobos may be distracted by high number of pull requests for heavily evolving modules
- code and binary size can go out of the limits of standard library
Proposed changes
To ensure high quality of new standard modules the drafting stage should be carried out using The D Drafting Library.
New names (naming is subject to change if suitable):
- Code name: Curiosity or Mars (Mars is already related to historical name for the D language)
- Root module: draft
The process modification can be visualized in the following picture:
The drafting library adds intermediate stage in the new modules development allowing the full flexibility without effecting the standard library. Contributors and users of Phobos can completely ignore the new library if they don't want to participate in adding new modules or use it in their software. The entry barrier for Curiosity is much lower than for Phobos but the development process driven by the community will ensure that final result quality will reach the most possible level.
- Prerequisites
- library should be placed at https://github.com/D-Programming-Language
- no external dependencies for new modules beside OS services
- development is monitored by wide audience
- all users should be aware about the usage consequences
- only well recognized community members have pull rights
- design decision made on the best known SW engineering patterns used in D
- new module should provide at least minimal functionality with D/Phobos standards applied
- API and implementation allowed to change any time in order to make a progress
- user can use a draft module to create a working product if the desired level of quality is achieved
- std.experimental can be used as a piloting stage for new modules coming into Phobos
- Proposal implementation steps
- Create an experimental library project at Github and verify the outcome
Note: New changes doesn't force current developers to perform any additional activities on their side
Usage
Usage is as simple as importing “std” module, but instead type “draft”:
import draft.newmodule;
Comparison to code.dlang.org packages
In general the DIP's idea is orthogonal to the code.dlang.org concept .
The following properties of “Curiosity” are not available or limited using code.dlang.org for development:
- community driven development as opposed to individually driven (ownership/control of the source code)
- out of the box readiness (Curiosity is available in installation process of DMD package, no compilation errors etc.)
- wide range of community members involved in the development to reduce controversy and fragmentation staring from the initial stage (development can't be hidden)
- no dependency hell
The code.dlang.org packages' status will remain unchanged. They can be used as a special purpose packages without a need of standardization burden.
Disadvantages
Additional minor changes in the SW release process to allow usage of the new library. The DMD installer shall be updated, so there is an option to install new library.
Credits
Special thanks to the following community members for critique and constructive comments (in order of appearance):
- Vladimir Panteleev
- Laeeth Isharc
- Israel
- Zach the Mystic
- weaselcat
- ZombineDev
- HaraldZealot
- Dicebot
- Tofu Ninja
Copyright
This document has been placed in the Public Domain.