<catepillar>
on configuration add your database instance to bot.shared, and then you can use it from all your plugins
<jmaister>
oh
<jmaister>
so bot.shared.db = Db::new, and then I can access it via bot.shared.db?
<jmaister>
But I'm actually leaning towards giving each plugin it's own DB even though it might be a bit overkill
ColdBlooder has quit [Remote host closed the connection]
<dominikh>
shared is a normal hash, so bot.shared[:db]
<catepillar>
^
<catepillar>
jmaister: it's generally easier to initialize it in bot.shared, and then if you don't want to access bot.shared[:db] every time you need something, you can set up a class variable, which contains a reference to the db object
<catepillar>
so you still have one only one object in memory
<dominikh>
don't use class variables.
<dominikh>
might as well not use bot.shared but a global variable if you did that
<catepillar>
but something feels wrong about globals... although i see your point
<dominikh>
class variables are glorified globals :)
<catepillar>
but more localized and controlled
<catepillar>
i suppose it depends on what you are building, and how cinch plays into that
[DS]Matej has quit [Changing host]
[DS]Matej has joined #cinch
[DS]Matej has quit [Changing host]
[DS]Matej has joined #cinch
<dominikh>
and still have potential to ruin your day once you want to run the same plugin multiple times, e.g. with multiple bots in one ruby instance
<dominikh>
coincidentally part of the reason we have Cinch 2 :P
<catepillar>
but if the entire script is just cinch, then a global var makes sense
<dominikh>
note, I was *not* recommending global variables
<dominikh>
I was discouraging the use of class variables