April 19, 2016 Re: stc.experimental.ndslice -> sci.ndslice | ||||
|---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Tuesday, 19 April 2016 at 01:13:01 UTC, deadalnix wrote:
> On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
>> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>>
>>
>> https://github.com/dlang/phobos/pull/4207
>
> sci as in ?
>
> If it is as in science, please just name this science. We have terabytes of hard drive, we can do with 4 extra characters.
It's the same reason why std is not called "standard" - programmers are pretty lazy and a top level module name does appear quite often.
| |||
April 19, 2016 Re: stc.experimental.ndslice -> sci.ndslice | ||||
|---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Tuesday, 19 April 2016 at 01:13:01 UTC, deadalnix wrote:
> On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
>> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>>
>>
>> https://github.com/dlang/phobos/pull/4207
>
> sci as in ?
>
> If it is as in science, please just name this science. We have terabytes of hard drive, we can do with 4 extra characters.
I decided to do not push packages to Phobos because it is not flexible. When Mir would contain enough good packages it may be packed with compiler.
| |||
April 22, 2016 Re: stc.experimental.ndslice -> sci.ndslice | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Dejan Lekic | On 04/18/2016 07:13 PM, Dejan Lekic wrote:
> On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
>> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>>
>>
>> https://github.com/dlang/phobos/pull/4207
>
> As I have said many times on both IRC and NG, I would prefer to have `stdx` instead of ridiculously long (4x) `std.experimental`. Then you would have a nice package named `stdx.sci`.
>
> PS. this is not my "invention" - Java community has `javax` for similar (but different, as nothing in javax is experimental) purpose!
Java is commonly mentioned as example of experimental package concept that didn't work at all.
| |||
April 22, 2016 Re: stc.experimental.ndslice -> sci.ndslice | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Ilya Yaroshenko | On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
> On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
>> On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote:
>>> On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev
>>>> I don't understand, what's wrong with std.sci or etc.sci?
>>>
>>> I am ok with std.sci for example. I just want to exclude dances with transaction between stable <->`experimental`. So, if all `std.sci` would be marked as experimental during few years this would what i want.
>>>
>> Another idea would be to go with std.experimental.sci.*, if that has a higher consensus.
>
> Just with std.sci.* without `experimental`. Otherwise this would be the same problem.
Why ... ? Just keep everything in std.experimental.sci until all the details are worked out, and only transition to std.sci in one go once it's all done.
| |||
April 23, 2016 Re: stc.experimental.ndslice -> sci.ndslice | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | On Friday, 22 April 2016 at 22:11:27 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
>> On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
>>> On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote:
>>>>[...]
>>> Another idea would be to go with std.experimental.sci.*, if that has a higher consensus.
>>
>> Just with std.sci.* without `experimental`. Otherwise this would be the same problem.
>
> Why ... ? Just keep everything in std.experimental.sci until all the details are worked out, and only transition to std.sci in one go once it's all done.
3-5 years... And then switch to D3.
| |||
April 23, 2016 Re: stc.experimental.ndslice -> sci.ndslice | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Ilya Yaroshenko | On Saturday, 23 April 2016 at 09:57:20 UTC, Ilya Yaroshenko wrote:
> On Friday, 22 April 2016 at 22:11:27 UTC, Joseph Rushton Wakeling wrote:
>> On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
>>> On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
>>>> On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko wrote:
>>>>>[...]
>>>> Another idea would be to go with std.experimental.sci.*, if that has a higher consensus.
>>>
>>> Just with std.sci.* without `experimental`. Otherwise this would be the same problem.
>>
>> Why ... ? Just keep everything in std.experimental.sci until all the details are worked out, and only transition to std.sci in one go once it's all done.
>
> 3-5 years... And then switch to D3.
I don't really see the analogy.
If we go your sci.* route, or std.sci.*, then the module naming suggests stability, and things require explicit documentation as experimental -- and the downstream user has to deal with the mental burden of unpicking what is not actually stabilized and reliable.
If we go with std.experimental.sci.*, then the module naming explicitly documents that the package as a whole is _not_ stabilized. You can document modules that _are_ considered as stable and reliable, and in doing so you're making a clearer promise to the downstream user.
You could also move stable std.experimental.sci modules to std.sci while providing deprecated public imports in the old std.experimental.sci module, and those could be maintained for the entire lifetime of std.experimental.sci (i.e. until the entire package is stabilized). So again, downstream users would only have to pay the full price of a breaking change once.
| |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply