hanzo has quit [Quit: Connection closed for inactivity]
<mooff>
an IRC bot library, composed of small modules
<ox1eef>
generally i would say it is not a good idea, storing things on the class is much like using globals
<mooff>
in which regards?
<ox1eef>
classes are usually referenced by constants that are accessible from everywhere in your program, including different threads. my rule of thumb is to keep as much as possible local to a given thread.
<mooff>
race safety, that's a reasonable point
<ox1eef>
i like how JS handles this, where other ES6 modules are references in the local scope.
<mooff>
don't ES6 imports give the same object, when used in different files, like CommonJS?
<ox1eef>
i don't think so, at least 'import foo from "foo.js"' followed by foo.bar = 1, keeps that change local to its scope. if you wanted your changes to hang around, probably you want to add them to 'window' or another global object.
<ox1eef>
it looks good, but id just repeat what i said before - do you really need class methods? couldn't the hooks be on the bot instance itself?
<mooff>
the hooks are, but the configure actions are there to add the hooks onto instances
<mooff>
classes fit nicely in their role as templates, i think
gr33n7007h has quit [Ping timeout: 240 seconds]
<ox1eef>
they're shared state by all bot instances though, and i think not neccessary. it seems that too could belong to the Bot instance.
<mooff>
i'm using it to run many bots in a process, and they're made / modified a lot at runtime
gr33n7007h has joined #ruby
<mooff>
it would be onerous to have to add behavior 'by hand' after an instance is constructed
<mooff>
especially when a lot.. for example, the PONG reply given by Bot::Pong.. is common to most instances
<ox1eef>
if you want to have multiple bots per process then it sounds like having each isolated to one thread with no shared state would be ideal. i dont fully understand what youre trying to do in terms of sharing behavior tho.
<mooff>
atm they do run! in separate threads, but their behavior is composed at a class level
<mooff>
i did want instances to be flexible. the on instance method is the thing that ultimately binds actions
<mooff>
how do you feel about ActiveModel, ActionController etc?
<ox1eef>
rails is the model thats proven itself most successful in ruby, and i think that speaks to itself. having said that, the rails model isnt the only model and at times it feels like one guys opinion.
<michigan>
Hi! I run this forum app on my main www.myapp.com, with two secondary apps photos.myapp.com and shop.myapp.com. Each are separate Rails apps. Should I keep it like that, or turn them all into a single app?
<michigan>
From what I understand the pros are: It would eliminate unnecessary code repetition and make upgrading and maintenance much easier. Having a single user database sounds nice too.
<michigan>
On the flipside, the app would be complicated by (please correct me if I'm wrong) namespaces, routes, tenants and possibly even Rails Engines. I'd also have to restructure everything in Git.
<weaksauce>
that's a tough question to answer
va5c0 has joined #ruby
<michigan>
Cool. That means it at least isn't a dumb question :-)
<weaksauce>
like anything there are tradeoffs
<weaksauce>
are they all bespoke projects?
<weaksauce>
how big?
_ht has quit [Remote host closed the connection]
<michigan>
Nope, they're all personal.
<weaksauce>
how are the apps architected right now?
<michigan>
The main app currently clocks in at 110 commits. The other ones around 50.