Andrei Alexandrescu wrote:
Benji Smith wrote:
Maybe if Andrei put together a list of
missing Phobos functionality, we could get people from the community
to flesh out the libs.
I think we'd need at a minimum:
<snip>
That would be great. In general, it would be awesome to gather more
contributions from the community. There's a thirst to contribute and
we'll be glad to involve this group into some serious design e.g. for
concurrency support, as well as accept code for functionality that
belongs to the standard library.
In the bulleted list above there are many mini-projects that are
confined enough to be done by one willing individual in a relatively
short time.
Are there contributor guidelines somewhere?
For example, should the author of a container library prefer classes or
structs? Should other (non-container) modules accept container classes
as arguments? Or only container interfaces (if there are any such
things) or just ranges?
Is it appropriate to use an empty struct purely as a namespace for the
introduction of free functions? Or should free functions be placed at
the module level?
Is it appropriate to define multiple classes, structs, templates, etc
within a single module? What considerations should inform the decision
regarding the placement of module boundaries?
What constitutes appropriate/inappropriate usage of opCall?
Anyhoo...
Point being, Phobos_1 was a hodgepodge of different conventions and
styles. Tango_1 was considerably better, in terms of stylistic
uniformity. But it used a very different set of idioms than Phobos_1
(lots of predicate functions, "sink" delegates, etc). Probably any
author contributing code to Phobos_2 should spend a little time getting
up to speed with the preferred idioms before writing code.
I suspect that my humble little JSON parser uses styles and idioms that
would clash with the majority of Phobos_2 (since my programming pedigree
comes from Java, C#, JavaScript, and Perl much moreso than C or C++).
--benji
