Benji Smith wrote:
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?
Not at the moment.
For example, should the author of a container library prefer classes or
structs?
I've been struggling with this forever. I don't know. I don't even know
whether reference or value semantics are best for containers. I don't
know whether abstract container interfaces and container-independent
code are a net win; experience with STL seems to say "don't" and
experience with Java seems to say "ho-hum".
Should other (non-container) modules accept container classes
as arguments? Or only container interfaces (if there are any such
things) or just ranges?
I think ranges should be preferred wherever applicable.
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?
I think module-level functions are best. If there are lookup issues due
to that, we need to fix the language. D is conceived to allow proper
coexistence of functions in different modules without forcing the user
to take too many precautions.
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?
I think it's appropriate because many pieces of functionality come as a
bundle. The rule of thumb is, module provides the functionality, and
it's up to the designer to decide what that entails.
What constitutes appropriate/inappropriate usage of opCall?
What examples do you have in mind?
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 agree. I am obviously subjective, but here are a few modules in
phobos2 that seem to me close to the desired look and feel:
* std.algorithm is a large collection of functions mostly operating on
one abstraction (ranges). If you know how to use one algorithm, you
probably know how to use all others. Defining ranges that std.algorithm
can work with is also a breeze.
* std.getopt is a very effective module. Although it does a fair amount
of stuff, it has a simple interface that can be learned in minutes. I
haven't seen an options parsing library that has the same power/ease
ratio. Its usage of static types to infer what you want to do is a good
showcase for the power of D templates and variadics.
* std.conv is simple (in interface), convenient, and general.
* std.range could use some maturing. I'm currently not 100% pleased
about it.
* std.file looks a bit quaint (e.g. no classes) but I'm comfortable
around it. It does what it's supposed to do and does it well.
* std.numeric is an example of a library that has a mix of functions and
objects collected under an umbrella topic. I'm ok with it, but at some
point I suspect I'd start worrying about its growth. Same about e.g.
std.typecons.
* std.md5 is an example on why it's not that advisable to just copy a C
interface into D. (This is a negative example.)
* std.random is a simple, extensible design, and has convenience
functions (such as uniform) that are, well, darn convenient. I see it
growing easily and nicely.
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++).
Phobos2 doesn't have (m)any hierarchies not because Walter or I don't
use them or like them. It's just that the particular stuff that's in
Phobos right now is at an advantage by using other design means. But if
you come with a good hierarchy implementing a piece of functionality, great.
Andrei
