D standard library group proposal (page 2)

February 04, 2004

Re: D standard library group proposal

Posted by Matthew
in reply to Lars Ivar Igesund

Permalink

Matthew

Posted in reply to Lars Ivar Igesund

Permalink

Here my two penn'th (that's "two cents' worth" for anyone not from Yorkshire
<g>):

I make comments inline, and then blither on at the end.

> Hi!
>
> I have made some sort of proposal to how the
> D Standard Library Group (DSLG) should be organized.

If this does take off, I think it should have a separate newsgroup, presumably D.SLG

> The group and it's organization is specified in 'grouprules'.
> The responsibilities are specified in 'responsibilities'.
> A (very short) style guide is presented in 'styleguide'.
>
> When it comes to group members, I would suggest;
>   In the main group: Burton Radons,
>                      Ben Hinkle,
>                      Sean L. Palmer,
>                      Justin Calvarese,
>                      Andy Friesen and
>                      myself :) (You're free to suggest
>                                 someone else.)

I'm not sure you've encompassed enough of the many talented folks here. Daniel springs to mind, as would several others if I was to turn off the "Hide Read Message" filter in my OE client.

Also, I know Sean's a very busy chap, so he, for one, might decline. The same may apply to others.

While I agree that the number of members is necessarily low, I'm not sure 6 is enough. I would think somewhere from 8-12 would be more appropriate. Remember that the prognostications of this group will not be at the same rate as traffic is digested, cogitated and responded in the normal group. Decisions will be informed upon by large amounts of information, relative to the number of "messages" (i.e. postings, emails, documents, etc.), so it seems unnecessary to limit the numbers participating; volume in this forum will derive from content length rather than content frequency. (If it doesn't, it's just going to degenerate into a spit-fight anyway.)

>   Review members:    Walter Bright and
>                      Matthew Wilson

I think Walter *MUST* be a reviewer. Were it otherwise, the SDLG would be a paper tiger.

As for myself, reviewing is one of the things that I'm truly good at - as opposed to those that I've forced myself to become competent at - so in that sense I would agree that I'm a good choice. (And I thank everyone who has said much the same thing in this thread; clearly I'm not as much of a dill as I thought you may have thought I may have been. Arf arf.)

The question of whether two is sufficient reviewers remains unanswered, though. Perhaps it is enough in the early stages, but I would suggest that there needs to be thought given *now* as to how a third reviewer would be added, and who that might be.

Walter's a very busy chap, and I would expect that his participation will necessarily be limited mostly to high-level reviews and vetos. Similarly, until the end of March I am insanely busy - I daren't even list out all the things I need to do in the next 6 weeks, as I fear I'll have an apoplectic fit if I see it all written down - and I would expect that I'd only have the same amount of time as Walter, so would only be into medium/high-level reviews and vetos. Perhaps that's all that's required of what you envisage of the review function, in which case your suggestion is correct that we two will be suitable.

> My suggestion will leave almost no power over phobos to Walter.

Here's where we have to disagree.

In IT, as in life, it's generally a bad idea to dissociate power and responsibility. However, in this case I would demur. I think Walter should continue to have ultimate (by which I mean final, rather all-encompassing) power for the DSLG.

I think any attempt to divest this power from Walter is doomed for two reasons. First, there's no real way for anyone to "steal" D away from Walter anyway. Second, I think most of us would strongly distrust any movement to bypass Walter; he's a very cluey bloke. For all that I disagree with him regularly on a variety of matters, I still know just what it is that I can do and what it is that he can do; remember he wrote the first front-to-back C++ compiler, and is one of only a handful of people in the world who understands all aspects of any current compiler.

> In the long run I believe it is necessary and
> probably good in the short run so he can concentrate on
> the compiler and language itself.

Walter does not need to be involved in the day-to-day aspects of Phobos, but he does need final say. I can't see that changing at any point; who would tell Bjarne Stroustrup that his opinions on C++ (or its standard library) are no longer important?

> Further, is it possible to use opend.org for this group?

I think this should be www.digitalmars.com/d/slg. If it needs access control - though I can't see why - I'm sure that can be arranged.

> Does it have a CVS repository?

An important point, about which I have no comment.

> Well, please discuss.

It continues inline below ...


----------------------------------------------------------------------------
----


> Mandate:
>  Manage the D standard library interface (see responsibilities).
>  Provide a sample implementation.

Sound ok. Although I would expect that the DSLG sample implementation would be Phobos, and would ship with DMD. Is this correct?

> Members:
>  The group should have 6 full members having one vote each.

As I said, I think it should be 8-12. This is discussed further shortly.

>  In addition, two review members should have half a vote each,
>  totalling 7 votes.

No. Review members have the following:

If there are 6 members with 1 vote each, then I think each review member should have:

Vote for: +2 points
Abstain: 0 points
Vote against: -2 points

If there are 10 members with 1 vote each, then each review member should have:

Vote for: +3 points
Abstain: 0 points
Vote against: -3 points

and so on and so on, with the review members votes totalling approx 40% of the total.

In practise, the ability for a review member to vote means that they must exercise great restraint and consideration in their decisions. This greater power is commensurate with their having more responsbility - there's nowhere to hide for review members!

I would envisage that review members would rarely do anything other than abstain, and leave the decisions to the normal members. This is inline with Walter's time constraints (and mine!). This would not be the case for major releases, breaking changes, etc. (discussed below)

A review member cannot abstain if the vote is deadlocked. Walter gets a casting vote in the case of a deadlocked vote involving all normal & reviewers.

> No member can set down a veto.

Walter has a veto.

>  The main members should be elected by the community (somehow).

It will probably make more sense for Walter to select between volunteers - assuming we get any - at least in the first instance.

It'd also be "nice" to have a mechanism by which people could be gently moved to the side with a minimum of fuss. But in reality I think the demands of everyday life and career will provide a natural winnowing mechanism: if a member is consistently on the losing side of every issue they will not be motivated to stay. (Of course, it's important to consider what's going on in such a circumstance. That lone voice might actually be the Einstein in the midst of a bunch of Newtonians!)

>  The review members should be Walter and Matthew(?) (IMHO).

Well, as I said, I am happy with that. But how can my opinion in this be unbiased?

To be dispassionate for a moment, I think it's axiomatic that Walter is the primary and permanent review member. Perhaps the other review member(s) should serve at Walter's pleasure? The alternative is some kind of voting mechanism, which is yet another layer of beaurocracy.

>  The main members sit in the group for 18 months each. 2 are
>  replaced every 6 months. (This means that of the first six,
>  two must leave after 6 months, and two after 12 months.)
>  Members can only sit in the group for two consecutive periods
>  (then there must be at least one period's pause).

This sounds way too complex for me. I think things will sort themselves naturally. Once it gets to a certain level of structure, the conditions can be decided at that time (or imposed by Walter in the case of a deadlock!).

>  The review members can sit as long as they want.

[Affecting godlike tone:] "But of course!"

[Seriously:] Refer to my comment above about the tenure of review members.


> Changes:
>  An API change needs at least 6 votes.

I think an additive change needs 51% of the vote, a deprecation change needs 70%, a breaking change needs 80%, and an ABI change requires 95%.

>  Patches to the implementation must be audited and approved by
>  at least three members.

Two for, none against.

>  Everyone can propose changes, but unless they are documented
>  and well founded, they will be rejected no matter what.

Of course!


----------------------------------------------------------------------------
----


> 1. Design of API
>    - The API decided upon by the group must be the
>       standard that all vendors conform to.
>    - The API should be feature complete with regard
>       to basic operations needed in modern applications
>    - Last point means that the API might change with time
>       as long as revision numbers can be used to make sure
>       that as few applications as possible are broken as
>       few times as possible.
>    - The group must strive for a stable API (as long as it
>       don't hinder new technologies).
>    - The group must strive for an API without bloat.
>    - All D compiler vendors must distribute a standard
>       library implementing this API.

I think there should be different "flavours". A compact lib would be useful in cases where an XML manipulating one would be off-putting or inhibitive, e.g. in an embedded environment. Maybe all that stuff can be left for post-1.0

>    - The API should be consistent over different platforms.
>    - The API must follow the API style guide.
>    - The API should not be just a wrapper for C APIs. As an
>       example, the Windows API should be provided in own
>       (preferebly standard) packages and shipped with the
>       compilers (like the Windows headers are with C
>       compilers).
>
> 2. Mantainer of sample implementation
>    - The group should mantain a sample implementation
>       (the first iteration should probably be Phobos).
>    - The sample implementation should be as stable as possible.
>    - The sample implementation should strive for correctness
>       before optimizations.
>    - The implementation should be as independent as possible.
>    - The implementation should follow the code style guide.
>


----------------------------------------------------------------------------
----


> 1. API style guide
>   - The API should be loosely coupled.
>   - Bloat must be avoided.
>   - Function names should be understandable.
>   - Function names should have each word except the first capitalized.
>
> 2. Code style guide
>   - In my opinion, Walter's style guide is mostly good enough.

- Single return is favoured, but not rigidly adhered to - no need to inflate
the size of a function to adhere
- Allman bracing is favoured. No more of that nasty K&R stuff. And none of
Walter's truly bizarre bracing, please! Hopefully some kind soul will write
a parser plug-in that reformats code according to the standard, so this'll
be moot

[btw Allman bracing is like the following:

class X
{
    this(. . . )
   {
        if(x)
        {

   . . . // etc

]

- a platform-wide ABI is defined prior to 1.0
- neither APIs + functions nor classes+methods are preferred where they do
not represent the optimally efficient and orthogonal solution, merely to
reflect one individual/group's "ideals" on what is the appropriate paradigm
of software engineering.



Ok, that's it from me. Discuss/flame/whatever

As I've indicated, I am happy to serve as a reviewer, since I think it's where I can deliver the biggest bang for my dimishing spare time. I can't imagine I'd have time to be a normal member (btw, can we call them full members, or administrative members, or something?), and I shall be most grateful to those that can and do.

One final word: I don't think there's any point in pursuing this idea much further until we hear from BigW. Walter?

Cheers

Matthew

Didn't i just know that it was smart to see what you thought?
Actually you probably put more time into your reply than I
did with my first proposal (I *did* think a lot about it, but
some lesser points (Walter's veto rights...) got thought about
a little less than I should have), meaning that I was bound
to change opinion on some points.

In general I tend to agree with most of the stuff you said.
The number of members I took out of the air, and the
suggested members where just my suggestion based on who I
felt where active (in both a historic and present perspective)
and with a strong interest. I know I left out some, often
coincidentally (long english words are 'pita's) and quite
possible those include either don't want to or don't have
the time to stay in the group.

As to whether the sample implementation should *be* phobos,
I guess so. As long as Walter is happy with it :)

Oh yes, I still believe that the group needs a webspace (for
documentation, rules of the group, ...) and definiately a
source control repository.

I vote to create such a group (me being a member is not a
prerequisite, I'll probably drop out due to too little time
anyway (teaching my two month old son to program is
timeconsuming)), so I'll keep (semi)quiet until more people
speak up.

Lars Ivar Igesund

Matthew wrote:

> Here my two penn'th (that's "two cents' worth" for anyone not from Yorkshire
> <g>):

Forums