New DIP73: D Drafting Library

[Piotrek via Digitalmars-d]

On Thursday, 5 February 2015 at 06:56:52 UTC, Dicebot wrote:
> You have clearly put a lot of effort in this. That makes me 
> very uneasy to repeat the same critique as earlier but, sadly, 
> it still all applies. This proposal tries to fix problems it 
> doesn't prove exist, doing so with solutions that are not 
> guranteed to help.

No need to be sorry. D needs quality guards.

> It also wrongly explains current process of inclusion into 
> Phobos in general and specifically std.experimental - being 
> probably one of more involved persons with Phobos review queue 
> I feel like this needs to be explained.
>
> Considering all the discussion that happened during 
> std.experimental.logger I understand that we have settled with 
> pretty much this:
>
> 1) All Phobos proposals must go through std.experimental.logger

When you say I put the current process wrongly, you mean there is 
no way to submit a new module avoiding a std.experimental 
namespace? Or something else? Can you provide a link to the 
latest official description? I will update the pictures.

> 2) It must implement something generally desired in Phobos
Which is?

> 3) Implementation is supposed to be at least stable enough to 
> not undergo a full rewrite after inclusion. Major API changes 
> are acceptable.

This point is one of the main problems the DIP tries to avoid.
According to your statement the module should be almost complete 
before the pull request is accepted. I mean without any design 
flows. In many cases that is really hard to achieve for one 
developer (e.g gui).
OTOH if you don't see the full implementation and can't test it 
you may not see the fundamental flows in design.
Of course this may be doable for less complex modules. Then the 
current way of using  std.experimental alone may be applicable.

> 4) Before DMD/Phobos release is made existing packages that 
> feel stable can undergo a formal review for inclusion in Phobos 
> main package
>
> With that in mind initial public review is supposed to only 
> determine if (2) and (3) is true which is mostly a formality as 
> people rarely propose modules they are not serious about.

How could you be sure that after long lonely work the proposal is 
worth inclusion?

> As you may see requirements are very lax. Only real difference 
> is that your poposal allows to accept modules that are not 
> supposed to ever go to Phobos at all - which I am still 
> convinced is a bad thing and belongs to code.dlang.org

How do you know what modules should not be in Phobos? Is there 
any widely accepted list? Even C++ is getting more "open minded".

> Speaking about objections vs code.dlang.org
>
>> community driven development as opposed to individually driven 
>> (ownership/control of the source code)
>
> see no reason to expect this is actually better of makes any 
> notable difference in general
>> out of the box readiness
>
> dub is planned to be distributed with DMD
>
>> wide range of community members involved in the development to 
>> reduce controversy and fragmentation staring from the initial 
>> stage
>
> no idea where this even comes from

Maybe I'm wrong but there is a big controversy and fragmentation 
e.g. in database and gui domain.

> Pretty much all extra goodies from DIP73 can be implemented by 
> creating special "officially endorsed" category in 
> code.dlang.org and showing it as a default package list at 
> code.dlang.org front page

This may lead to competing packages. How would we decide what are 
the "proper" packages. There can be impossible to fully control 
the development by the whole community (yes I know I repeat 
myself).

> In general, there needs to be a good analysis backing the 
> proposal to change anything - good intention and good idea 
> alone are not enough.

Fully agree. Of course I provided only ideas based on my personal 
experience and NG posts. Any hint what else I could do is welcome.

> It is better to do nothing than do something unless one is 
> extremely sure that it will help.

I guess there is always risk there. But I agree that we should be 
convinced about the progress beforehand.

Piotrek