www.digitalmars.com         C & C++   DMDScript  

D - D standard library group proposal

reply Lars Ivar Igesund <larsivar igesund.net> writes:
Hi!

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

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.)
  Review members:    Walter Bright and
                     Matthew Wilson

My suggestion will leave almost no power over phobos to
Walter. 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.

Further, is it possible to use opend.org for this group?
Does it have a CVS repository?

Well, please discuss.

Lars Ivar Igesund
Feb 02 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
my 2 cents: I know you mean well but I don't think this group is needed (at
the moment).


 When it comes to group members, I would suggest;
   In the main group: Burton Radons,



                      Ben Hinkle,


ack. Can I unsuggest myself? Not to be ungrateful but I haven't put *any*
thought into where phobos should go. I know I'm working on getting the GCC
port and it would be nice to keep the standard library portable but I think
people are generally aware of the issues and the design decisions made so
far seem very reasonable w.r.t. portability.

What are the general proposals for changes to Phobos? I haven't been paying
that much attention.

I seem to recall Matthew saying he was going to tackle DTL (which I just
assumed was the D equivalent to STL). This would be a big part of any
standard library and I assumed it would go in phobos eventually. I also seem
to recall Walter saying he'd like to keep any GUI toolkit separate from the
standard library, which makes sense to me, too.


                      Sean L. Palmer,
                      Justin Calvarese,
                      Andy Friesen and
                      myself :) (You're free to suggest
                                 someone else.)
   Review members:    Walter Bright and
                      Matthew Wilson

 My suggestion will leave almost no power over phobos to
 Walter. 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.


Personally I'd like Walter and Matthew to be heavily involved in the design.
I trust them to "do the right thing". Since Walter has driven Phobos this
far I'm nervous about switching drivers - especially to a gaggle of drivers.
Besides, this really is his "baby" and if he wants help with Phobos I'm
comfortable waiting until he asks for it.

Eventually you are probably right that some independent group should take
ownership. I'm just not convinced any group we could muster at the moment
would do a better job than the current setup of Walter driving and us
shouting directions from the back seat. Imagine how it feels to him reading
over and over "Are we there yet? How much longer? I gotta pee."

-Ben


 Further, is it possible to use opend.org for this group?
 Does it have a CVS repository?

 Well, please discuss.

 Lars Ivar Igesund
Feb 02 2004
next sibling parent reply "Phill" <phill pacific.net.au> writes:
 Personally I'd like Walter and Matthew to be heavily involved in the


design.

 I trust them to "do the right thing". Since Walter has driven Phobos this
 far I'm nervous about switching drivers - especially to a gaggle of


drivers.

 Besides, this really is his "baby" and if he wants help with Phobos I'm
 comfortable waiting until he asks for it.


I agree with your opinion.

 I'm just not convinced any group we could muster at the moment

 would do a better job than the current setup of Walter driving and us
 shouting directions from the back seat. Imagine how it feels to him


reading

 over and over "Are we there yet? How much longer? I gotta pee."


and here I agree again.

No offence meant to the guys that have been suggested as "members", as
Im REAL sure they know a hell of a lot more than I do about D.

But you must agree this is Walter's domain and he is damn good at it, so
why risk it, when it is about to become real big?

Phill.
Feb 02 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Phill wrote:


 But you must agree this is Walter's domain and he is damn good at it, so


Not according to the man himself (see my attachment in my answer to
Ben).

Lars Ivar Igesund
Feb 03 2004
parent "Phill" <phill pacific.net.au> writes:
I dont want to get into a big arguement about this, as
I am only a concerned user of D.

But I think this suggestion by you pushes it a bit far:

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

I just think it is his vision and everyone(almost) seems to like it . I just
hope that it doesnt get changed for the worse.
 I think that Walter and Mathew should still make suggestions and have a
powerfull say in the direction it goes in(even if they dont do the actual
coding), as well as Review.

Again this is not meant as a critisism.

Phill.

"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bvp64b$1av5$2 digitaldaemon.com...

 Phill wrote:


 But you must agree this is Walter's domain and he is damn good at it, so


 Not according to the man himself (see my attachment in my answer to
 Ben).

 Lars Ivar Igesund
Feb 03 2004
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Ben Hinkle wrote:

 my 2 cents: I know you mean well but I don't think this group is needed (at
 the moment).


Hmm, well I don't agree. :)


 
 

When it comes to group members, I would suggest;
  In the main group: Burton Radons,


 
 

                     Ben Hinkle,


 
 
 ack. Can I unsuggest myself? 


Of course :)


 What are the general proposals for changes to Phobos? I haven't been paying
 that much attention.


Not really of relevance in this discussion, IMHO, although there are
several issues that needs to be resolved, both with regard to the
already existing API, the implementation of it and missing features.
And documentation.


                     Sean L. Palmer,
                     Justin Calvarese,
                     Andy Friesen and
                     myself :) (You're free to suggest
                                someone else.)
  Review members:    Walter Bright and
                     Matthew Wilson

My suggestion will leave almost no power over phobos to
Walter. 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.


 
 Personally I'd like Walter and Matthew to be heavily involved in the design.
 I trust them to "do the right thing". Since Walter has driven Phobos this
 far I'm nervous about switching drivers - especially to a gaggle of drivers.
 Besides, this really is his "baby" and if he wants help with Phobos I'm
 comfortable waiting until he asks for it.


Walter has made some guidelines to how he thinks phobos
should be organized (see the attached post), and as I
understand it, he asked for help. He don't have the time
to concentrate on phobos in addition to the language and
compiler.


 Eventually you are probably right that some independent group should take
 ownership. I'm just not convinced any group we could muster at the moment
 would do a better job than the current setup of Walter driving and us
 shouting directions from the back seat. Imagine how it feels to him reading
 over and over "Are we there yet? How much longer? I gotta pee."


I believe that any group we could muster would be able to do
*something*, which is more than Walter (sorry to say this) has
done in a long while (zlib being the exception confirming the
rule.) As long as the guidelines for the group is strict, I don't
think that it will take too many wrong directions. Personally I
wouldn't mind Walter being able to veto changes, but to pipe
all changes through him would destroy any momentum.

And at last, and I hope you didn't mean to, but I find your
argumentation somewhat belittling.

Lars Ivar Igesund
Feb 03 2004
parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
 And at last, and I hope you didn't mean to, but I find your
 argumentation somewhat belittling.


Sorry about that. I didn't intend any offense. Your proposal is well thought
out and I didn't mean to belittle anyone.
-Ben
Feb 03 2004
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Ben Hinkle wrote:

And at last, and I hope you didn't mean to, but I find your
argumentation somewhat belittling.


 
 
 Sorry about that. I didn't intend any offense. Your proposal is well thought
 out and I didn't mean to belittle anyone.
 -Ben
 


Good, good! Sorry to subject you to such charges.

Lars Ivar Igesund
Feb 03 2004
prev sibling next sibling parent reply "C" <dont respond.com> writes:
While I think its a good idea and it is definitely time to speed up phobos
development , I don't know that something so bureaucratic is necessary ( or
likely to be accepted ).

We do however need a way to address issues with phobos as they come up ,
recently the eof() issue (
http://www.digitalmars.com/drn-bin/wwwnews?D/22760 ) , the Win98 GC
misbehaving ( http://www.digitalmars.com/drn-bin/wwwnews?D/22303 ) , and
even possibly having a choice between garbage collectors (
http://www.digitalmars.com/drn-bin/wwwnews?D/23097 ) etc...

Perhaps let Matthew filter out requests for changes and accompanying
patches( through a simple HTML form on digitalmars ) , and let Walter have
the final approval ?

Right not there is no direct way to address these issues , we just throw it
up here in hopes Walter will read it / respond , and often times thats
unfulfilling because you never get an answer , and you don't know if he saw
it and refused , or didn't see it etc...

Its a tricky subject , but one that I thing needs to be addressed

IMO ( everyone's got em :) )
C


"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bvmk6r$2jto$1 digitaldaemon.com...

 Hi!

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

 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.)
   Review members:    Walter Bright and
                      Matthew Wilson

 My suggestion will leave almost no power over phobos to
 Walter. 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.

 Further, is it possible to use opend.org for this group?
 Does it have a CVS repository?

 Well, please discuss.

 Lars Ivar Igesund



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



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

 Members:
  The group should have 6 full members having one vote each.
  In addition, two review members should have half a vote each,
  totalling 7 votes. No member can set down a veto.
  The main members should be elected by the community (somehow).
  The review members should be Walter and Matthew(?) (IMHO).
  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).
  The review members can sit as long as they want.

 Changes:
  An API change needs at least 6 votes.
  Patches to the implementation must be audited and approved by
  at least three members.
  Everyone can propose changes, but unless they are documented
  and well founded, they will be rejected no matter what.



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



 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.
    - 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.
Feb 03 2004
parent Lars Ivar Igesund <larsivar igesund.net> writes:
C wrote:


 While I think its a good idea and it is definitely time to speed up phobos
 development , I don't know that something so bureaucratic is necessary ( or
 likely to be accepted ).


I'm of the opinion (you might have noticed already ...) that a
bureaucratic (and democratic) approach is better than a dictatorship.


 Perhaps let Matthew filter out requests for changes and accompanying
 patches( through a simple HTML form on digitalmars ) , and let Walter have
 the final approval ?


Relying on one person is probably the least efficient possibility, at
least when that person is busy with something else. Probably, members
of the group should have less possibility to veto by not voting, or
voting against.
If Walter should have the right to veto, it should be after a suggested
change has been through the mill of the group (hopefully this can be
a efficient process.), leaving a as little burden on him as possible.

Lars Ivar Igesund
Feb 03 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Just to let you know I've read it, but am frazzled atm. Give me a few days,
and let's hear some more opinions, and then I'll shoot off my thoughts.

I know it's not like me to hang back when there's an opportunity for put
forth my half-considered ideas, but I think this is an important issue, and
deserves my time and respect before I post thoughts/decisions.

"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bvmk6r$2jto$1 digitaldaemon.com...

 Hi!

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

 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.)
   Review members:    Walter Bright and
                      Matthew Wilson

 My suggestion will leave almost no power over phobos to
 Walter. 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.

 Further, is it possible to use opend.org for this group?
 Does it have a CVS repository?

 Well, please discuss.

 Lars Ivar Igesund



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



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

 Members:
  The group should have 6 full members having one vote each.
  In addition, two review members should have half a vote each,
  totalling 7 votes. No member can set down a veto.
  The main members should be elected by the community (somehow).
  The review members should be Walter and Matthew(?) (IMHO).
  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).
  The review members can sit as long as they want.

 Changes:
  An API change needs at least 6 votes.
  Patches to the implementation must be audited and approved by
  at least three members.
  Everyone can propose changes, but unless they are documented
  and well founded, they will be rejected no matter what.



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



 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.
    - 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.
Feb 03 2004
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Matthew wrote:


 Just to let you know I've read it, but am frazzled atm. Give me a few days,
 and let's hear some more opinions, and then I'll shoot off my thoughts.
 
 I know it's not like me to hang back when there's an opportunity for put
 forth my half-considered ideas, but I think this is an important issue, and
 deserves my time and respect before I post thoughts/decisions.


I'll hold my breath as I value your thoughts highly.

Lars Ivar Igesund
Feb 03 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bvp6jo$1c0e$2 digitaldaemon.com...

 Matthew wrote:


 Just to let you know I've read it, but am frazzled atm. Give me a few




days,

 and let's hear some more opinions, and then I'll shoot off my thoughts.

 I know it's not like me to hang back when there's an opportunity for put
 forth my half-considered ideas, but I think this is an important issue,




and

 deserves my time and respect before I post thoughts/decisions.


 I'll hold my breath as I value your thoughts highly.


That might be a cardinal mistake!

LOL!
Feb 03 2004
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Matthew wrote:


 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:bvp6jo$1c0e$2 digitaldaemon.com...
 

Matthew wrote:



Just to let you know I've read it, but am frazzled atm. Give me a few




 
 days,
 

and let's hear some more opinions, and then I'll shoot off my thoughts.

I know it's not like me to hang back when there's an opportunity for put
forth my half-considered ideas, but I think this is an important issue,




 
 and
 

deserves my time and respect before I post thoughts/decisions.


I'll hold my breath as I value your thoughts highly.


 
 
 That might be a cardinal mistake!


As it always might be when listening to others advice :)
Feb 03 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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
Feb 03 2004
parent Lars Ivar Igesund <larsivar igesund.net> writes:
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>):
Feb 04 2004
prev sibling parent Friedrich Dominicus <frido q-software-solutions.com> writes:
Well I just repeat myself I'm afraid, but writing reusable libraries is 
one of the most challenging things in Software Development. I just want 
to remind you of how difficult it was to get STL out.

The problem I see is with time constraints. I assume the proposed 
members do all have their "normal programming" job, so I don't think 
that they can much time on it.

Have you though about checking other reusable libraries and re-implement 
them in D?

I suggest to check out the GOBO library. It is written for Eiffel, but 
works for any of the available Eiffel compilers because it just relies 
on a few Kernel classes. What might be useful about it especially is 
that is used DBC which is very good supported in D. So you would get a 
reasonable specification right from the start. GOBO is now at least 5 
years old, so it is definitly a "stable" library.

Regards
Friedrich
Feb 09 2004