On Tue, 14 May 2013 15:37:50 -0400 Nick Sabalausky <seewebsitetocontac...@semitwist.com> wrote:
> On Tue, 14 May 2013 04:35:20 +0200 > "Nathan M. Swan" <nathanms...@gmail.com> wrote: > > > 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. > Hmm, there is a problem: For Vibe.d, mysql-native's Connection class is expected to derive from EventedObject. But EventedObject is part of Vibe.d. I'm not sure offhand how to handle that without making mysql-native's Connection templated.