I don't think I like the proposed change.
First of all, from my experience, the async APIs are used a lot less than
sync ones, so having 2 lines of code for async calls is not a big deal in
my view.
Secondly, the scope of this change would be huge. We would have to double
our Compute, Cache, Services, and many other APIs. Seems to me like a huge
amount of effort for a very questionable benefit, if any at all. One can
argue, for example, that so many duplicate sync/async methods on all the
APIs is more confusing, not less.
And lastly, I am against having .NET APIs different from Java APIs. We
should have API parity as much as possible between all the platforms, and
especially the .NET one, where we provide so many features.
On Fri, Oct 9, 2015 at 7:05 AM, Pavel Tupitsyn <ptupit...@gridgain.com>
wrote:
> As a .Net dev, I support this change very much.
>
> Current design with 2 method calls is not easy to use, is error prone, and
> is not familiar to .Net crowd:
>
> var cache = ignite.GetCache<int, int>().WithAsync();
> var value = cache.Get(1); // Is it sync or async? Can't tell from code.
In async mode this always returns 0.
>
Yes, you are right. But then again, async documentation clearly says that
you should get a future to get the actual asynchronous result.
The proper code here is:
-----------
var cache = ignite.GetCache<int, int>().WithAsync();
// Line #1
cache.Get(1);
// Line #2
cache.Future().Get();
-----------
2 lines of code instead of one is not a big deal in my view.
> var future = cache.GetFuture<int>(); // User has to specify right generic
> argument here. Not convenient, error prone, violates design guidelines
> var actualValue = await future.ToTask();
>
>
> As opposed to:
> var value = await cache.GetAsync(1).ToTask();
>
> Which is one line, obviously async, with proper generic inference.
>
>
>
> On Fri, Oct 9, 2015 at 4:47 PM, Vladimir Ozerov <voze...@gridgain.com>
> wrote:
>
> > 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.
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>
