On 1/2/17 12:09 AM, Jacob Carlborg wrote:
On 2017-01-02 02:34, Adam Wilson wrote:
That was my intention, the knee-jerk reaction that class and interfaces
get here sometimes strikes me as a bit histrionic sometimes. They are a
tool with a use case. :)
I think that the design should try to avoid classes as much as possible
for things that will be frequently created. It's always possible to wrap
a struct in a class, the other way around is a bit more difficult. But
when it comes to the connection object I think it's fine to use classes
since it will most likely only be created once per thread.
Ok. How would you design a database API for D?
The requirements I am operating under are:
1. Individual data-store driver implementations are not included in the
D Standard Library. Driver licensing and implementation details vary.
For example libpq5 uses it's own mix of licenses that is not Boost
compatible.
2. The D Standard Library provides a common API and implementation of
shared components, but leaves the data-store specific implementation up
to the implementer. We don't care how the implementation is constructed
or licensed, only that the API is followed.
3. In order to support higher level abstractions like ORM's we need a
base class model that can be extended by implementers but still consumed
by the ORM without knowing implementation specific details.
As far as I am aware, the only way to meet those requirements is to use
a base-class model. Is there something I am missing?
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
