Igniters,
Some time ago we decided to merge sync and async methods. E.g. instead of
...
interface Cache<K, V> {
V get(K key);
Future<V> getAsync(K key);
}
... we now have:
interface Cache<K, V> extends AsyncSupport {
V get(K key);
Cache withAsync();
Future lastFuture(); // From AsyncSupport, returns future for the last
operation.
}
This approach is questionable. Less methods is good, and all methods go
through JCache API. But async mode became more complex and less usable.
This is especially obvious in Java 8 with its lambdas and CompletableFuture.
In .Net we blindly applied this approach as well. But in this world
AsyncSupport gives even less advantages than in Java:
1) There is no JCache spec here;
2) Core .Net API very often use paired sync and async operations in the
same class near each other - DoMethod(), DoMethodAsync() - and this is what
users normally expect from async-enabled classes.
3) [AsyncSupported] attribute is not highlighted in Visual Studio. The only
way to understand that method supports async mode is to install ReSharper
or to look into source code.
4) .Net has native continuations support with async/await keywords. Our API
doesn't support it well.
Having said that I want to return paired "async" operations to .Net API:
interface ICache<K, V> {
V Get(K key);
IFuture<V> GetAsync(K key);
}
It will add 25 new methods to ICache interface and remove 2. But API will
become much more friendly and natural for .Net users.
Any thoughts/objections?
Vladimir.
