On Saturday, 3 June 2017 at 06:37:27 UTC, H. S. Teoh wrote:
On Sat, Jun 03, 2017 at 02:16:16AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
On Friday, 2 June 2017 at 20:37:05 UTC, H. S. Teoh wrote:
> Especially the bit about throwing away years of accumulated > programming work.

Our IRC discussion was more about simplifying the Phobos interface through breaking changes than actually just dropping and rewriting. Most the "phobos 2" would just be today's phobos with mistakes changed, autodecoding deprecated then removed, eager functions same deal (the discussion that started it was split vs splitter), static array interfaces removed (you'd have to explicitly slice at the call site instead of Phobos trying to two-layer ref them), etc.

So step one of this would be to copy existing code. Then cut the mistakes out.

The modified modules are just given a new package name (or something)
to ease the transition.

Now that you put it this way, this suddenly seems a lot less disruptive and intimidating than it first sounded.

And it sounds more possible to actually use the deprecation cycle to gradually pull this off, as opposed to throwing out the baby with the bath water and restarting from ground zero.

And by putting the modified modules in a new temporary namespace, we can ease the transition enough that perhaps we might actually see this happen, one day. (Haha, so I hope.)


T

Same will there come to be a need to replace Phobos 2 (when it happens) with 3 all because we prefer things to be renamed and relocated... when we've not fully discovered what phobos currently offers or improvements to be made.

stdx.data.json was not well documented last time I checked. Couldn't see any major benefit over std.json besides the performance claim. Besides, phobos is an MVP, there are more faster dub packages and nothing stops u from using them.

Does it really matter if it belongs in the std namespace?

Reply via email to