www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Questions about phobos additions mentioned in 2015H1 vision document

reply "Gary Willoughby" <dev nomad.so> writes:
In the 2015H1 vision document[1] it states the following:

<quote>
*Foster additions to the standard library and third-party 
libraries*
We prefer adding new components to the standard library over 
refactorings and reorganizations of those that work (barring bug 
fixes). Our vision is to foster a large standard library 
complemented by a strong battery of third-party libraries. 
Aspects like networking, concurrent/parallel/distributed 
programming, and database connectivity are of interest to place 
in the standard library.
</quote>

1. Are you wanting a large "batteries included" standard library 
a'la Python[2] or only focused around the aspects mentioned?

2. When implementing something like 'std.database' do you see 
this as bindings to libraries (similar to std.net.curl[3]) or an 
implementation of the relevant specification/protocols etc. to 
negate the need for dependencies?

3. When mentioning networking, do you mean email handling, http 
servers, sockets etc? Do you see this replacing std.net.curl?

[1]: http://wiki.dlang.org/Vision/2015H1
[2]: https://docs.python.org/3.4/library/
[3]: http://dlang.org/phobos/std_net_curl.html
Apr 05 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/5/15 10:48 AM, Gary Willoughby wrote:

 In the 2015H1 vision document[1] it states the following:

 <quote>
 *Foster additions to the standard library and third-party libraries*
 We prefer adding new components to the standard library over
 refactorings and reorganizations of those that work (barring bug fixes).
 Our vision is to foster a large standard library complemented by a
 strong battery of third-party libraries. Aspects like networking,
 concurrent/parallel/distributed programming, and database connectivity
 are of interest to place in the standard library.
 </quote>

 1. Are you wanting a large "batteries included" standard library a'la
 Python[2] or only focused around the aspects mentioned?


Batteries included.


 2. When implementing something like 'std.database' do you see this as
 bindings to libraries (similar to std.net.curl[3]) or an implementation
 of the relevant specification/protocols etc. to negate the need for
 dependencies?


Universal. I think ODBC is the best option here.


 3. When mentioning networking, do you mean email handling, http servers,
 sockets etc? Do you see this replacing std.net.curl?


All of the above. Some may build on curl, some may complement it, some 
may replace some of its functionality.


Andrei
Apr 05 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 1. Are you wanting a large "batteries included" standard 
 library a'la
 Python[2] or only focused around the aspects mentioned?


 Batteries included.


This is a quite significant decision. It has both advantages and 
disadvantages. (I think Rust has chosen to have a lighter std 
lib).

Bye,
bearophile
Apr 05 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/5/15 12:02 PM, bearophile wrote:

 Andrei Alexandrescu:


 1. Are you wanting a large "batteries included" standard library a'la
 Python[2] or only focused around the aspects mentioned?


 Batteries included.


 This is a quite significant decision. It has both advantages and
 disadvantages. (I think Rust has chosen to have a lighter std lib).


No doubt we must go with a large stdlib. Virtually all but a couple 
languages are experiencing significant growth in stdlib. -- Andrei
Apr 05 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 6/04/2015 6:31 a.m., Andrei Alexandrescu wrote:

 On 4/5/15 10:48 AM, Gary Willoughby wrote:

 In the 2015H1 vision document[1] it states the following:

 <quote>
 *Foster additions to the standard library and third-party libraries*
 We prefer adding new components to the standard library over
 refactorings and reorganizations of those that work (barring bug fixes).
 Our vision is to foster a large standard library complemented by a
 strong battery of third-party libraries. Aspects like networking,
 concurrent/parallel/distributed programming, and database connectivity
 are of interest to place in the standard library.
 </quote>

 1. Are you wanting a large "batteries included" standard library a'la
 Python[2] or only focused around the aspects mentioned?


 Batteries included.


 2. When implementing something like 'std.database' do you see this as
 bindings to libraries (similar to std.net.curl[3]) or an implementation
 of the relevant specification/protocols etc. to negate the need for
 dependencies?


 Universal. I think ODBC is the best option here.


 3. When mentioning networking, do you mean email handling, http servers,
 sockets etc? Do you see this replacing std.net.curl?


 All of the above. Some may build on curl, some may complement it, some
 may replace some of its functionality.


 Andrei


On that note, anyone willing to help create and ODBC host via Derelict 
or will I be doing something like that?
Apr 05 2015
next sibling parent reply "Suliman" <evermind live.ru> writes:
Andrei, if vibed will include in DMD distribution, would it's 
mean that common libs (like json) will be merged with DMD? I 
think it would very rational step.
Apr 07 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/7/15 10:22 AM, Suliman wrote:

 Andrei, if vibed will include in DMD distribution, would it's mean that
 common libs (like json) will be merged with DMD? I think it would very
 rational step.


You mean in std? Some if not all, but each needs to pass review. -- Andrei
Apr 07 2015
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Monday, 6 April 2015 at 03:19:03 UTC, Rikki Cattermole wrote:

 On that note, anyone willing to help create and ODBC host via 
 Derelict or will I be doing something like that?


I don't understand this sentence. :/
Apr 07 2015
prev sibling next sibling parent "Jonas Drewsen" <nospam4321 hotmail.com > writes:
 3. When mentioning networking, do you mean email handling, 
 http servers,
 sockets etc? Do you see this replacing std.net.curl?


 All of the above. Some may build on curl, some may complement 
 it, some may replace some of its functionality.


I would like to see e.g. libasync mature a bit and get into 
std.async. From there http, ftp... client and server could be 
added to std.net if we want to.

I am currently using libasync in Deadcode with great success.

https://github.com/etcimon/libasync

/Jonas
Apr 10 2015
prev sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Sunday, 5 April 2015 at 18:31:37 UTC, Andrei Alexandrescu
wrote:

 On 4/5/15 10:48 AM, Gary Willoughby wrote:
 Universal. I think ODBC is the best option here.


Maybe it is for std.database.sql or std.database.relational


Andrea
Apr 10 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 11/04/2015 9:12 a.m., Andrea Fontana wrote:

 On Sunday, 5 April 2015 at 18:31:37 UTC, Andrei Alexandrescu
 wrote:

 On 4/5/15 10:48 AM, Gary Willoughby wrote:
 Universal. I think ODBC is the best option here.


 Maybe it is for std.database.sql or std.database.relational


 Andrea


Yeah, for NoSQL it could be an interesting issue.

And on that note, I already have bindings to ODBC drivers.
But does anyone wanna write the driver manager parts to it?

https://github.com/DNetDev/odbc_drivermanager
Apr 10 2015