Timeline for Is an interface exposing async functions a leaky abstraction?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 19, 2019 at 16:27 | answer | added | Scott Hannen | timeline score: 0 | |
| Jan 28, 2019 at 22:25 | comment | added | Frank Hileman | @StarTrekRedneck Is a pure function (no side effects) asynchronous or synchronous? Does it matter, when trying to understand it? Part of what I was poking at was reducing the scope of the are where we even think about the difference between asynchronous and synchronous, and where we do think about it, separating the functionality from the "plumbing". This is where the functional people seem to be doing better. | |
| Jan 17, 2019 at 14:02 | vote | accept | Enrico Massone | ||
| Jan 17, 2019 at 12:00 | history | tweeted | twitter.com/StackSoftEng/status/1085869478376861696 | ||
| Jan 17, 2019 at 11:55 | answer | added | Mark Seemann | timeline score: 8 | |
| Jan 17, 2019 at 11:04 | comment | added | max630 | softwareengineering.stackexchange.com/questions/382486/… | |
| Jan 17, 2019 at 8:24 | history | edited | Enrico Massone | CC BY-SA 4.0 | deleted 15 characters in body |
| Jan 15, 2019 at 21:28 | comment | added | StarTrekRedneck | :-) -> The "functional programming people" ha. Async is no more leaky than synchronous, it just seems that way because we're used to writing sync code by default. If we all coded async by default, a synchronous function might seem leaky. | |
| Jan 15, 2019 at 17:11 | answer | added | gnasher729 | timeline score: 11 | |
| Jan 15, 2019 at 16:47 | answer | added | John Wu | timeline score: 2 | |
| Jan 14, 2019 at 21:49 | comment | added | Frank Hileman | There are a number of answers and comments explaining why the asynchronous nature of the method is part of the abstraction. A more interesting question is how a language or programming API can separate the functionality of a method from how it is executed, to the point where we no longer need Task return values, or async markers? The functional programming people seem to have figured this out better. Consider how asynchronous methods are defined in F# and other languages. | |
| Jan 14, 2019 at 19:23 | answer | added | Daniel T. | timeline score: -2 | |
| Jan 14, 2019 at 17:08 | answer | added | Filip Milovanović | timeline score: 3 | |
| Jan 14, 2019 at 16:36 | comment | added | richzilla | I would argue the 'asyncness' of a method is indicated by the fact that it returns a Task. The guidelines for suffixing async methods with the word async was to distinguish between otherwise identical API calls (C# cant dispatch based on return type). At our company we've dropped it all together. | |
| Jan 14, 2019 at 15:25 | comment | added | Enrico Massone | @Neil actually there is a naming guideline which states that all async methods should have a name ending in "Async". But this does not imply that a method returning a Task or a Task<T> must be named with the Async suffix because it could be implemented by using no async calls. | |
| Jan 14, 2019 at 15:22 | comment | added | Enrico Massone | @Neil I probably got the point. An interface exposing methods returning Task or Task<T> is not a leaky abstraction per se, is simply a contract with a signature involving tasks. A method returning a Task or Task<T> does not imply having an async implementation (for instance if I create a completed task by using Task.CompletedTask I'm not doing an async implementation). Vice versa, the async implementation in C# requires that the return type of an async method must be of type Task or Task<T>. Put another way the only "leaky" aspect of my interface is the async suffix in names | |
| Jan 14, 2019 at 15:02 | answer | added | BobDalgleish | timeline score: 6 | |
| Jan 14, 2019 at 14:46 | answer | added | Neil | timeline score: 0 | |
| Jan 14, 2019 at 14:33 | history | asked | Enrico Massone | CC BY-SA 4.0 |