Last update May 30, 2007

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".

Table of contents of this page
What should the name of the project be?   
Should it have a different module namespace from std?   
Who's in charge and what should their authority be?   
How should the library be designed?   
Links   

What should the name of the project be?    

Should it have a different module namespace from 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?    

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?    

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).

Links    


FolderProjects

FrontPage | News | TestPage | MessageBoard | Search | Contributors | Folders | Index | Help | Preferences | Edit

Edit text of this page (date of last change: May 30, 2007 21:56 (diff))