RFC: mysql-native - Supporting both Vibe.d and Phobos sockets

[Nick Sabalausky]

On Tue, 14 May 2013 04:35:20 +0200
"Nathan M. Swan" <nathanmswan at gmail.com> wrote:
> On Sunday, 12 May 2013 at 21:16:33 UTC, Nick Sabalausky wrote:
> > There is need for mysql-native
> > <https://github.com/rejectedsoftware/mysql-native> to support 
> > both
> > Vibe.d's sockets and Phobos sockets.
> >
> > Since Phobos's and Vibe.d's sockets have incompatible APIs, my 
> > design
> > converts most of the types in mysql-native into templates. For 
> > example,
> > 'Connection' becomes either 'Connection!mySQLSocketVibeD' or
> > 'Connection!mySQLSocketPhobos'. The type 'Command' becomes 
> > either
> > 'Command!mySQLSocketVibeD' or 'Connection!mySQLSocketPhobos'. 
> > And the
> > same goes for most other types, such as Row, ResultSet, etc.
> >
> 
> Does "incompatible APIs"

By "incompatible APIs" I just meant that I can't use structural/duck
typing on them (at least not directly), and they don't have a common
base type aside from Object.

> preclude a design like this?
> 
> -----
> interface MysqlSocket {
>      // ...
> }
> 
> class PhobosSocket : MysqlSocket {
>      this(std.socket.Socket _backend) {
>          // ...
>      }
>      // ...
> }
> 
> class VibeSocket : MysqlSocket {
>      this(vibe.core.net.TCPConnection _backend) {
>          // ...
>      }
> }
> -----
> 

That's actually somewhat similar to what I ended up doing internally: I
created a minimal wrapper for std.socket.Socket to expose a vibe-like
socket API (but only for what's actually necessary for mysqln, nothing
more, so it isn't a general, full-fledged phobos->vibed socket
adapter). Then, based on how the templates are instantiated, the socket
will be typed as either vibe.core.net.TCPConnection or the
internally-defined phobos socket wrapper. I had some reasons for doing
it that way, however...

However, now that you mention it, I think you're right, I should be
able to just add a trivial pass-through wrapper for Vibe.d's sockets,
define a minimal common interface for that and the Phobos socket
wrapper, and just pass that interface into Connection.this().

There were some reasons I didn't go down that route before, but now
that I think about more, I don't think those reasons were valid. And
this definitely leads to a much cleaner design and API, plus it's more
powerful (can use subclasses of either socket type). And while virtual
method invocation isn't free, it should be completely negligible
compared to actually performing network I/O, even if it's just
localhost.

I'm going to try that, see how it plays out.

> Sorry if I've overlooked anything obvious,
> NMS

I think I'm the one who was overlooking things ;) Thanks!