On 06/09/2015 10:56 AM, luminousone via Digitalmars-d wrote:
On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote:
My work on allocators takes the last turn before the straight line.
I've arranged with Dicebot to overlap the review period with
finalizing details so I can act on feedback quickly.
After that I'm ready for some major library work, and I had two
things in mind.
One would be a good pass of std.container, in particular (a) a design
review with the DbI glasses on; (b) better documentation - sadly it
seems to me so inadequate as to make containers themselves unusable;
(c) investigate use of UFCS - std.container's design predates UFCS
yet is a perfect fit for it, and most likely other cool language
improvements we've added since.
The other would be database connectivity. Erik Smith has shown some
cool ideas at DConf, and I encourage him to continue working on them,
but it seems to me this is an area where more angles mean more
connectivity options.
For database connectivity I'm thinking of using ODBC. What I see is
that on all major platforms, vendors offer mature, good quality ODBC
drivers, and most programs that have anything to do with databases
offer ODBC connectivity. So connecting with ODBC means the individual
database drivers are already there; no need to waste effort on
creating drivers for each (or asking vendors to, which we can't afford).
So I gave myself ten minutes the other night just before I went to
sleep to see if I can get an ODBC rig on my OSX machine starting from
absolutely nothing. I got http://www.odbcmanager.net but then got
confused about where to find some dumb driver (text, csv) and gave up.
Last night I gave myself another ten minutes, and lo and behold I got
up and running. Got a demo CSV driver from
http://www.actualtech.com/product_access.php (which also supports
Access and others). Then I headed to
http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and
was able to run a simple ODBC application that lists the available
drivers. Nice!
It's trivial work to convert the C headers to D declarations. Then
it's straight library design to offer convenient libraries on top of
the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have
database connectivity for all databases out there!
Please help me choose what to work on next.
Andrei
I would think a good database lib would depend on a good container
lib, So IMO, the order is self evident.
1000+ to containers.
I'd say what it depends on is good serialization. If you extend
containers to include disk based B+Trees then I'd agree with you,
otherwise not.
