stop_server not usable from within defstart about exactor

[sasa1977]

Yes, the valid macros from which stop_server/1 can be used are documented here.

I guess for the sake of completion we could add macros for :ignore and {:stop, reason :: any}. The problem is that stop for defstart (which is init/1) would have to be differently named, so I wonder if it's worth it, because you can just return {:stop, reason}. The main motivation behind the existing responder macros was to have pipe friendly interface, so you can just pipe the state into the callback return value. IMO, that advantage is less relevant with the {:stop, reason} and :ignore tuples, so I currently have some reservations about adding the support for them.

[sasa1977]

Yes, good idea. I’ll think a bit about this, and then either document the intent better, or add the macros you requested. Thanks for pointing this out!

On 31 Mar 2016, at 01:11, OvermindDL1 [email protected] wrote:

True, I just like consistency in how functions visually flow, and some control functions ending in tuples and some ending in functions is just a touch jarring, but I am currently using {:stop, reason} right now. The piping is good reasoning for them, perhaps document that that is their purpose to help dissuade this?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #17 (comment)

[OvermindDL1]

For note, the tuple in init for :stop is: {:stop, reason}
Thus no state is needed.

[OvermindDL1]

True, I just like consistency in how functions visually flow, and some control functions ending in tuples and some ending in functions is just a touch jarring, but I am currently using {:stop, reason} right now. The piping is good reasoning for them, perhaps document that that is their purpose to help dissuade this?