On Tue, 03 Jan 2017 13:23:55 +0100, Jacob Carlborg wrote: > On 2017-01-03 09:38, Chris Wright wrote: > >> You are unable to interact with two different databases in the same >> executable using the same library. For instance, if you're using >> hibernated, either you compiled it to connect to mysql, or you compiled >> it to connect to oracle. > > That's true. And that's why I said it's difficult to design an API > without trying it in code :)
I didn't try it in code. >> In exchange, you get...slightly less GC usage. It's not *no* GC usage >> -- >> you'll see a bunch of buffers allocated to hold incoming and outgoing >> messages. You'll just peel back one layer of it. > > 1. I hope there won't be that many buffers in the API, at least not in > the user facing API The returned row data is mandatory, and its size can be much larger than the stack limit. (A MySQL MEDIUMBLOB field will likely break your stack limit.) I suppose you could have a streaming API for row data, one that has a stack-allocated buffer and returns slices of that: string fieldName; ubyte[] data; ubyte[][string] fields; db.query("SELECT * FROM USERS") // have to revisit this if a db allows large names .onFieldStart((fieldName) => field = fieldName) .onFieldData((fragment) => data ~= fragment) .onFieldEnd(() { fields[field] = data; data = null; }) .onRowEnd(() => process(fields)) .onResultsEnd!(() => writeln("done")) .exec(); This looks pretty terrible, to be honest. I get this sort of thing from nodejs because it doesn't want to potentially block and also doesn't want to delay letting me process things, but the worst I get there is usually two callbacks. This would also result in more GC use for the majority of people who use the GC. > 2. Buffers say nothing how they're allocated. With classes on the other > hand, you're basically forced to allocate with the GC You haven't looked at std.experimental.allocator, have you? http://dpldocs.info/experimental-docs/std.conv.emplace.3.html http://dpldocs.info/experimental-docs/std.experimental.allocator.make.html http://dpldocs.info/experimental-docs/ std.experimental.allocator.dispose.2.html