2 ms·

I recently had to make a change that converted a few functions to be async. It was certainly annoying to propagate that back in all the signatures, but the bigg

by ziml77 5y ago

I recently had to make a change that converted a few functions to be async. It was certainly annoying to propagate that back in all the signatures, but the biggest issues came with having code that was designed under the assumption that the code would be synchronous. It was difficult to rework the code in ways that would avoid issues with things like the fact that if I use a member variable, call one of these functions, and then use use that variable again, there's no longer a guarantee that the variable still has the same value. And for issues like that I don't think that having async from the start would have helped much. Because if the signature said async but everything actually completed synchronously, it's possible that people would have been more conscious about those issues, but it's also very likely that plenty of cases would be missed. Testing wouldn't expose any problems unless the implementations were swapped out for code that was actually running asynchronously. It's not easy to call what the right approach is. The best you can do is try to guess what the most likely future is and code for that. Violating the YAGNI principle can end up adding extra work and complexity and even reduced performance for no payoff later.

aksss 5y ago
> use a member variable, call one of these functions, and then use use that variable again, there's no longer a guarantee that the variable still has the same value. Could you expound upon this? Not sure I understand the context, but would like to. Are you assigning a value to a member variable by awaiting the return of an async method, not clear would cause you to lose the value.
galaxyLogic 5y ago
I've had similar situations where what initially seems like a simple change between async vs. sync can turn out to be a major redesign effort. Therefore I'm starting to lean on the idea that I should use more async -methods from the start than what I'm currently doing. Part of the issue is that 'sync' is the default. I wonder if it would be better the other way. Because sync is the default it is easy to "simply" write sync methods in cases where async might be a better choice, and, that decisions is often hard to reverse later. I'm working with JavaScript but I assume the issues and questions are similar as with c#. I think the question could be rephrased as "When should I NOT use async methods?"

by ziml77 5y ago

aksss 5y ago

> use a member variable, call one of these functions, and then use use that variable again, there's no longer a guarantee that the variable still has the same value. Could you expound upon this? Not sure I understand the context, but would like to. Are you assigning a value to a member variable by awaiting the return of an async method, not clear would cause you to lose the value.

galaxyLogic 5y ago

I've had similar situations where what initially seems like a simple change between async vs. sync can turn out to be a major redesign effort. Therefore I'm starting to lean on the idea that I should use more async -methods from the start than what I'm currently doing. Part of the issue is that 'sync' is the default. I wonder if it would be better the other way. Because sync is the default it is easy to "simply" write sync methods in cases where async might be a better choice, and, that decisions is often hard to reverse later. I'm working with JavaScript but I assume the issues and questions are similar as with c#. I think the question could be rephrased as "When should I NOT use async methods?"