Phobos Rising
Difference (last change) (Author, normal page display)
Changed: 3,4c3,4
This project was renamed to Ares ( DsourceProject:ares). The Ares project was deprecated in favor of Tango ( DsourceProject:tango) on 2007/01/02. |
|
* This project was renamed to Ares ( DsourceProject:ares). * The Ares project was deprecated in favor of Tango: ( http://www.dsource.org/projects/tango) on 2007/01/02. |
A new project to create a new "Phobos".
- This project was renamed to Ares ( DsourceProject:ares).
- The Ares project was deprecated in favor of Tango: ( http://www.dsource.org/projects/tango) on 2007/01/02.
What should the name of the project be? 
- Suggestions: http://www.dsource.org/forums/viewtopic.php?t=320
- Vote: http://www.dsource.org/forums/viewtopic.php?t=326
Should it have a different module namespace from std?
- Naming the namespace: http://www.dsource.org/forums/viewtopic.php?t=314
- Compiler dependencies on in ''std''
- Someone is going to have to do some pretty serious hacking to find out what the minimal compilable source tree is. Just keep removing stuff from a phobos build until you can't build simple objects and scalar types anymore.
- If it helps, I do know for a fact that the compiler is sensitive to what goes in phobos/src/typeinfo. I once hacked together a "ti_void.d" that allowed me to do (very evil) things with "void". I'm not at all advocating that we go adding scalar types like crazy, but it shows how dependent on that tree dmd is.
- I also haven't a clue what impact this kind of hacking will have on the GCC fontend, if any.
Who's in charge and what should their authority be?
- Steering Group?: http://www.dsource.org/forums/viewtopic.php?t=315
- DSLG: http://www.dsource.org/forums/viewtopic.php?t=329
- Boost-style review process?:
- Boost works in a similar way to what I was envisioning here. The committee consists of all mailing list members. Formal submissions require a list sponsor who volunteers to be the review manager (so there's no one person with more authority than any other). All list members are welcome to submit formal reviews and it is the review manager's job to sort through all the information and reject or accept the submission. Pre-submission evaluation is kind of unstructured and happens both on the list and in other forums. In our case, I had proposed that Deimos be the venue for pre-review discussion, since that's pretty much what it was intended for in the first place. The full description of the Boost process is here: http://boost.org/more/formal_review_process.htm
How should the library be designed?
- Coding Standards: http://www.dsource.org/forums/viewtopic.php?t=317
- Project Direction and Features: http://www.dsource.org/forums/viewtopic.php?t=316
- OO vs free functions
- My opinion is that the decision about whether to use classes or free functions should be based on whether the 'thing' stores any state. If it stores state then use a class, otherwise use free functions.
- Library modules should "private import" other modules unless there's a strong reason for a public import (and that reason should be documented).
- Based off of existing style guides?
Links
- Forum at dsource: http://www.dsource.org/forums/viewforum.php?f=31
- DocComments/Phobos
- Phobos
- BestPractices
- StandardLibrary (this idea has come up before)