On Thu, 16 May 2013 19:10:32 -0400
Nick Sabalausky SeeWebsiteToContactMe@semitwist.com wrote:
I don't know if you've noticed on the D NG, but I'm trying to make
mysql-native compatible with both Vibe.d sockets and Phobos-only
sockets.Instead of a template-based solution (which I tried, but it led to
some awkwardness in the API), I was thinking of just making a minimal
internal-to-mysqln interface, say 'MySQLSocket' and create minimal
wrappers over both std.socket.Socket and vibe.core.net.TCPConnection
which implement that interface. Then the user could pass whatever type
of socket into msqln's Connection ctor, and mysqln would just use it
as a 'MySQLSocket'.But the problem is, for Vibe.d, mysqln's Connection derives from
the EventedObject interface. Since EventedObject is part of Vibe.d,
it's a no-go for Phobos-only users. And naturally I can't derive from
it conditionally without going back to templating it.So my question is, what's the reason, or reasons, why mysqln's
Connection is, or needs to be, an EventedObject? Is it just because
of the connection pooling in 'mysql/db.d' (because I think I can work
around that easily enough), or are there other reasons? Or do you have
any other suggestions/insight to the matter?
To be more to-the-point:
What I'm thinking of doing is changing mysql-native's Connection to
contain an EventedObject (when using Vibe.d sockets instead of Phobos
sockets) instead actually being an EventedObject. Then I'd adjust the
'mysql.db.MysqlDB' connection pool accordingly (and probably
rename it something like MySqlDBConnectionPool while I'm at it, and
make a note that it's for Vibe.d-only).
My question is: Do you see any problems with that approach?