RejectedSoftware Forums

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?

Actually - I can't yet say for sure, but it's very likely - the
EventedObject interface can probably be removed completely at some
point. It's only purpose was to provide the generic event ownership
mechanisms (acquire/release) and those have been removed on master.
It could be that there will be other methods that allow waiting on
multiple objects later, but these will not be needed by ConnectionPool.

But since this is not yet in a released version, it doesn't help that
much anyway.

Btw., if we assume that mysql-native in conjunction with vibe.d is
always built with DUB, instead of MySQLNNoVibeD, an additive approach
using the automatically defined Havevibe_d version could be used, too.

Am 19.05.2013 06:50, schrieb Nick Sabalausky:

And it is exactly "Havevibed", right? Also, is that already
supported in DUB, or just in DUB master, or yet-to-be-implemented?

Yes, should be the exact spelling and it's supported in DUB since some
versions. Just when using the old "vibe" shell script, it wouldn't
automatically work, but that is hopefully at the end of its life anyway...