You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we can chat-data-structure but this kinda smells.
Instead we could return a go channel that any background processes could put on. The command handling pipeline would take values from it and post them to chat.
Not sure if that channel would need to be explicitly closed when the command is done. 🤔
The text was updated successfully, but these errors were encountered:
Not sure if that channel would need to be explicitly closed when the command is done. i was pondering the same thing @devth -- and i don't have a clear path forward in my brain ..
i can see where it would be nice to NOT have that burden placed on me, a command developer -- but at the same time, i like it when things are explicit ..
in HUBOT, you just use the send command as you please .. in ERRBOT, you yield results when appropriate and/or return a result to be sent ..
if all we had was some syntactic sugar for chat-data-structure -- i would walk away pretty happy .. at least it gives me a clear, non-smelly path forward to send messages to the user as i see fit ..
sure, a go channel would be pretty legit, since i like the pub/sub elegance of it .. but at the same time, i don't want to be "burdened" with having to remember to close the channel at the end of my command ..
just some random thoughts on this -- thanks for taking it into consideration ..
Currently we can
chat-data-structure
but this kinda smells.Instead we could return a go channel that any background processes could
put
on. The command handling pipeline wouldtake
values from it and post them to chat.Not sure if that channel would need to be explicitly closed when the command is done. 🤔
The text was updated successfully, but these errors were encountered: