The recent discussion about std.random suggested that we need a transitioning scheme for certain modules and packages in std that provide different designs without breaking the existing ones.

C++ has things like std::tr1 and #if __cplusplus >= 201103L. We also need to have separate names for modules that are redone with incompatible APIs, such as std.random or std.json. For a while now I was thinking along the lines of std.v2.random, std.v2.json etc. but that is misleading - it suggests the entire std has a v2 version from which we pick some specific modules. In reality, it's only specific modules that have a v2 version. So I have a low-tech idea and a high-tech one:

* Low-tech: just use std.random_v2, std.json_v2, etc. Leave std.random, std.json etc be and put them in maintenance mode. Possibly deprecate them later if the v2 versions work great.

* High-tech: use std.random.v2, std.json.v2, etc. This entails more administrative work (convert modules to packages etc) but may have some advantages due to the version being a separate symbol instead of embedded in the name.

So I'm leaning toward the low-tech approach unless evidence comes up that the other is better.

The clear message here is that we do need to make good strides toward replacing artifacts that need replacing without being crippled by backward compatibility.

So if Ilya wants to merge his random work (heh) into std, he would start with std.experimental.random_v2, and then upon approval move that to std.random_v2.


Andrei

On Friday, 25 November 2016 at 16:10:51 UTC, Andrei Alexandrescu wrote:
> The recent discussion about std.random suggested that we need a transitioning scheme for certain modules and packages in std that provide different designs without breaking the existing ones.
>
> C++ has things like std::tr1 and #if __cplusplus >= 201103L. We also need to have separate names for modules that are redone with incompatible APIs, such as std.random or std.json. For a while now I was thinking along the lines of std.v2.random, std.v2.json etc. but that is misleading - it suggests the entire std has a v2 version from which we pick some specific modules. In reality, it's only specific modules that have a v2 version. So I have a low-tech idea and a high-tech one:
>
> So if Ilya wants to merge his random work (heh) into std, he would start with std.experimental.random_v2, and then upon approval move that to std.random_v2.

The new Random module was builded in Better C concept in mind.
Comparing with ndslice, random module has precompiled code. And we need to solve not only the naming problem. We need integration with dub where we can select and download/override/recompile appropriate desired version of a Phobos part like random.

This is very important for potential contributors and companies.

I think that Better C Phobos packages may have their own prefix, like `ext.` (external extension from community). Or, better, `mir.`, hehe

Thanks,
Ilya

On 11/25/2016 11:39 AM, Ilya Yaroshenko wrote:
> The new Random module was builded in Better C concept in mind.
> Comparing with ndslice, random module has precompiled code. And we need
> to solve not only the naming problem. We need integration with dub where
> we can select and download/override/recompile appropriate desired
> version of a Phobos part like random.
>
> This is very important for potential contributors and companies.

I don't know of precedent in other languages whereby the standard library is built by mixing and matching third-party components. At some point we need to commit to supporting a core standard library. Having folks replace parts of it may be allowed but to support it formally seems a bit much.

At any rate it would be good to treat this as an orthogonal matter. Don't let that prevent you from doing good work in std.

> I think that Better C Phobos packages may have their own prefix, like
> `ext.` (external extension from community).

There are any number of cross-cutting concerns that one might want to look at a library. Which parts are safe? Which parts don't throw? Which parts need the GC? Which parts rely on the runtime? And so on. Ascribing hierarchical namespaces to some or all of these seems counterproductive. Just document is as "this module does not rely on the runtime" and move on.

> Or, better, `mir.`, hehe

If receiving appropriate recognition/branding for your work on the standard library is important to you, I'll be glad to discuss that privately.


Thanks,

Andrei

On Friday, November 25, 2016 11:10:51 Andrei Alexandrescu via Digitalmars-d wrote:
> The recent discussion about std.random suggested that we need a transitioning scheme for certain modules and packages in std that provide different designs without breaking the existing ones.
>
> C++ has things like std::tr1 and #if __cplusplus >= 201103L. We also need to have separate names for modules that are redone with incompatible APIs, such as std.random or std.json. For a while now I was thinking along the lines of std.v2.random, std.v2.json etc. but that is misleading - it suggests the entire std has a v2 version from which we pick some specific modules. In reality, it's only specific modules that have a v2 version. So I have a low-tech idea and a high-tech one:
>
> * Low-tech: just use std.random_v2, std.json_v2, etc. Leave std.random, std.json etc be and put them in maintenance mode. Possibly deprecate them later if the v2 versions work great.
>
> * High-tech: use std.random.v2, std.json.v2, etc. This entails more administrative work (convert modules to packages etc) but may have some advantages due to the version being a separate symbol instead of embedded in the name.
>
> So I'm leaning toward the low-tech approach unless evidence comes up that the other is better.
>
> The clear message here is that we do need to make good strides toward replacing artifacts that need replacing without being crippled by backward compatibility.
>
> So if Ilya wants to merge his random work (heh) into std, he would start with std.experimental.random_v2, and then upon approval move that to std.random_v2.

Two other alternatives:

1. Move std/json.d into std/json/package.d, and then add the new stuff as modules in std/json/ but don't have std/json/package.d publicly import anything from std.json.*. It would have the advantage of not breaking any code while allowing us to still use std.json longterm. The downside is that you couldn't import std.json and get the new stuff until the old stuff had gone through the whole deprecation process, and it could be confusing in that normally, when something is both a package and a module, importing the module imports the whole package, which it wouldn't do in this case for a couple of years.

2. Make the new json be something like std.data.json. We'd already talked about doing that before. Then the new xml stuff could go in std.data.xml. It avoids the whole v2 thing by further reorganizing Phobos in a hierarchical manner.

In the case of std.json, I definitely favor going with the std.data.* suggestion, since I think that it's cleanest, and it avoids the whole v2 problem altogether. Unfortunately, that still leaves the std.random problem, since I'm not aware of an equivalent to std.data.* for std.random nor is there any organizational reason AFAIK to put it somewhere else in the hierarchy.

So, for std.random, I don't know. The "high-tech" approach has problems similar to my first alternative with regards to confusion of importing std.random vs std.random.v2, but it's not as bad with the high-tech approach, because it's clearly in a sub-package/module rather than effectively being directly in the same package and getting different versions based on whether you import the package or the individual modules. That being the case, std.random_v2 is probably better, but it just seems ugly IMHO. Then again _any_ solution with v2 is ugly. Long term, we could alias it to std.random, but we'd have to leave the v2 there or be needlessly breaking folks code just for a name change. So, the "low-tech" approach is probably best when it doesn't make sense to move it somewhere else in the package hierarchy, but I don't particularly like it, and in the cases where it makes sense to move the module to make it more hierarchical (as seems to be the case with json and xml), then I favor that approach.

- Jonathan M Davis

On 26/11/2016 6:16 AM, Jonathan M Davis via Digitalmars-d wrote:
> 2. Make the new json be something like std.data.json. We'd already talked
> about doing that before. Then the new xml stuff could go in std.data.xml. It
> avoids the whole v2 thing by further reorganizing Phobos in a hierarchical
> manner.
>
> In the case of std.json, I definitely favor going with the std.data.*
> suggestion, since I think that it's cleanest, and it avoids the whole v2
> problem altogether. Unfortunately, that still leaves the std.random problem,
> since I'm not aware of an equivalent to std.data.* for std.random nor is
> there any organizational reason AFAIK to put it somewhere else in the
> hierarchy.
>
> So, for std.random, I don't know. The "high-tech" approach has problems
> similar to my first alternative with regards to confusion of importing
> std.random vs std.random.v2, but it's not as bad with the high-tech
> approach, because it's clearly in a sub-package/module rather than
> effectively being directly in the same package and getting different
> versions based on whether you import the package or the individual modules.
> That being the case, std.random_v2 is probably better, but it just seems
> ugly IMHO. Then again _any_ solution with v2 is ugly. Long term, we could
> alias it to std.random, but we'd have to leave the v2 there or be needlessly
> breaking folks code just for a name change. So, the "low-tech" approach is
> probably best when it doesn't make sense to move it somewhere else in the
> package hierarchy, but I don't particularly like it, and in the cases where
> it makes sense to move the module to make it more hierarchical (as seems to
> be the case with json and xml), then I favor that approach.
>
> - Jonathan M Davis

std.math.random

Well it does deal with numbers pretty much solely.

On 11/25/2016 09:15 PM, rikki cattermole wrote:
> std.math.random

The idea here is not to find new tricks for each of the modules we want to evolve, but instead devise a systematic migration path. -- Andrei

On Friday, 25 November 2016 at 16:10:51 UTC, Andrei Alexandrescu wrote:
> * Low-tech: just use std.random_v2, std.json_v2, etc. Leave std.random, std.json etc be and put them in maintenance mode. Possibly deprecate them later if the v2 versions work great.
>
> * High-tech: use std.random.v2, std.json.v2, etc. This entails more administrative work (convert modules to packages etc) but may have some advantages due to the version being a separate symbol instead of embedded in the name.

My favorite solution is the std.v2.random. Hoping std.v2.stdio works and it's an alias to std.stdio.

In this way it's easier to read documentation (I just need to go to doc/v2).

If you write a vXX for each packet we'll have:

std.v5.random
std.stdio
std.v2.json

And it's quite confusing.

IMHO:

std.v5.random
std.v5.stdio == std.stdio == std.v2.stdio == std.v3.stdio == std.v4.stdio
std.v5.json == std.v3.json == std.v4.json

is easier to work with (we simply choose an api level/snapshot of phobos).


Moreover I think that a new version of a module can have dependencies from another new module. I mean: std.v5.random could depend on std.v3.math. I'm using std.math and I'm not aware of this dependency and probably it is going to break something (or at least to generate more code than necessary).

Instead if i use std.v5.random and std.v5.math they are all on the same level and all dependencies should work fine.

Maybe we can define a const (just like c++) PHOBOS_API_LEVEL = XX we can override with a dmd flag (but set to max level inside phobos source) so we can avoid ugly xxx.v3.yyy names if not needed.

Andrea

On 11/28/2016 04:13 AM, Andrea Fontana wrote:
> Hoping std.v2.stdio works and it's an alias to std.stdio.

That doesn't work - how do you later make breaking changes to std.v2.stdio? We'd be missing the very point of doing this. -- Andrei

On Monday, 28 November 2016 at 13:34:42 UTC, Andrei Alexandrescu wrote:
> On 11/28/2016 04:13 AM, Andrea Fontana wrote:
>> Hoping std.v2.stdio works and it's an alias to std.stdio.
>
> That doesn't work - how do you later make breaking changes to std.v2.stdio? We'd be missing the very point of doing this. -- Andrei

It's just an api level. When you need a breaking change all modules will be updated to v3 as alias except the edited ones.

V3 it just like a commit-id on github.

On Monday, 28 November 2016 at 13:42:30 UTC, Andrea Fontana wrote:
> On Monday, 28 November 2016 at 13:34:42 UTC, Andrei Alexandrescu wrote:
>> On 11/28/2016 04:13 AM, Andrea Fontana wrote:
>>> Hoping std.v2.stdio works and it's an alias to std.stdio.
>>
>> That doesn't work - how do you later make breaking changes to std.v2.stdio? We'd be missing the very point of doing this. -- Andrei
>
> It's just an api level. When you need a breaking change all modules will be updated to v3 as alias except the edited ones.
>
> V3 it just like a commit-id on github.

So every (breaking) phobos release import the last version of each module.

If i have an old code to support i just need to compile with:

dmd .... -version=PHOBOS_API_LEVEL_2

and

import std.stdio; // will import std.v2.stdio instead of predefine std.v3.stdio