Timeline for Must we define methods and async when we don't know whether the implementation is synchronous or asynchronous?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 5, 2019 at 23:34 | comment | added | Scott Hannen | Oddly I had moved on when I stumbled across this purely by accident. blog.ploeh.dk/2019/02/11/asynchronous-injection | |
| May 5, 2019 at 23:25 | vote | accept | Scott Hannen | ||
| May 5, 2019 at 23:24 | comment | added | Scott Hannen | I didn't ask this question well because I'm confirming my understanding of the mechanics (accomplished) while asserting conclusions that result from that understanding. In other words, part of my question was a question and the other part is an opinion. I've made it messy. | |
| May 5, 2019 at 22:51 | comment | added | Fabio | Task is not an implementation details, but part of the abstraction contract. Do you want consumer of the abstraction to be able to consume it asynchronously? If yes - use Task if not - don't use it. | |
| May 3, 2019 at 19:16 | comment | added | Scott Hannen | That it's not abstracted away is exactly what I'm trying to clarify. Thanks | |
| May 3, 2019 at 19:05 | comment | added | whatsisname | @ScottHannen: in that scenario, you rarely can just switch async in and out willy nilly without problems. While the .NET Task library does a good job of abstracting syncronization issues away, it doesn't do so perfectly, and you can very easily find deadlocks in async/await code, especially from 3rd party libraries. Async/await is a very high level, fundamental design choice. | |
| May 3, 2019 at 19:02 | comment | added | Scott Hannen | I don't think that whether it's an implementation detail or a fundamental design decision is quite so black and white, either/or. Suppose I have an existing async method that depends on a third-party library. It has no async method so I don't await it. Then they provide an async method, and I await it. To me that's more of an implementation detail than a design decision. | |
| May 3, 2019 at 19:02 | comment | added | whatsisname | @ScottHannen: it's virtually impossible to abstract something you know nothing about and end up with an abstraction that improves the situation. Don't be so anxious to just write off "implementation details" because the devil is in the details, and it's not uncommon to discover a little detail that ends up being a significant amount of work to resolve. | |
| May 3, 2019 at 18:43 | comment | added | D Drmmr | Sync or async is not an implementation detail. It is a fundamental design decision. You need to make that decision based on the information you have now (or gather more info first). The price of making the wrong decision is either an overcomplicated design or having to redesign later. I'd go for the latter. | |
| May 3, 2019 at 18:16 | comment | added | Scott Hannen | The ambiguity of IDependency is deliberate. And, since it's an abstraction, I'd rather not have to decide how the implementation is going to work before I create the interface. Making sure that I understand whether or not I must do that is actually at the very heart of my question. My understanding is that we just have to work around that the best we can, which is I suppose is okay since no one has found it to be huge concern. | |
| May 3, 2019 at 18:08 | answer | added | Robert Harvey | timeline score: 3 | |
| May 3, 2019 at 18:06 | comment | added | Robert Harvey | I'm inclined to agree. IDependency says very little about the operating characteristics of DoSomething(). | |
| May 3, 2019 at 18:05 | comment | added | whatsisname | Why can you not just figure out more of what IDependency is going to do and how it's going to work before building the class using it? | |
| May 3, 2019 at 17:52 | history | edited | Robert Harvey | CC BY-SA 4.0 | deleted 11 characters in body |
| May 3, 2019 at 17:26 | history | asked | Scott Hannen | CC BY-SA 4.0 |