Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CA+0=VoUn=HzutOWy5einjs2SECp7g03FHrNi9gekpTbLhAWiSA@mail.gmail.com>
References: 
 <CAGt6o8=BmZKxeX0s3iBA_kLvJDej5diPZupNxd0oW1-2kmgiow@mail.gmail.com>
 <CAK2_iMP8vdaGn_iYbMdpYS4GabbFOdr6SohTdoGYAQd=WKA+Cg@mail.gmail.com>
 <CA+0=VoVC2_CYe9M2SsJVH5TdmKPth_QbBeVjYwnb-qy-NjcBzg@mail.gmail.com>
 <CAK2_iMO6mW6oR1sp80FsdVgnWQOiRzbG7j+VpC+RgkFR0ac1mg@mail.gmail.com>
 <CA+0=VoUn=HzutOWy5einjs2SECp7g03FHrNi9gekpTbLhAWiSA@mail.gmail.com>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Sat, 10 Oct 2015 12:39:20 +0300
Message-ID: 
 <CA+eZwrG22YCGNAcb0mWj9gLzFt-XKFUq3t1MVWbQeyAA0gdeQA@mail.gmail.com>
Subject: Re: .Net: separate methods for async operations.
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a11440fa23f4ecc0521bce1d7

--001a11440fa23f4ecc0521bce1d7
Content-Type: text/plain; charset=UTF-8

I think IgniteAsyncSupport is a big piece of crap even in java, sync/async
API separation definitely must be done in another way.

Sergi

2015-10-10 0:40 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> Pavel, can you explain how .NET async semantics are different from Java?
>
> On Fri, Oct 9, 2015 at 1:46 PM, Pavel Tupitsyn <ptupitsyn@gridgain.com>
> wrote:
>
> > Hi Dmitry,
> >
> > > First of all, from my experience, the async APIs are used a lot less
> > than sync
> > ones
> >
> > This may be true, especially if the API is clunky.
> > But .NET has async/await functionality which makes async code a lot
> cleaner
> > and easier.
> > Good async/await support is very important, because it does not block
> > current thread, which in turn is important for high load applications.
> > All modern .NET APIs are async.
> >
> >
> > > Secondly, the scope of this change would be huge.
> >
> > I don't think so. There are around 40 methods with async support in
> current
> > Ignite.NET.
> > Adding their async counterparts will take a couple of hours at most.
> > And it will simplify interop code somewhat because GetFuture goes away.
> >
> >
> > > And lastly, I am against having .NET APIs different from Java APIs.
> >
> > Functionally they will be the same. But we should not try to bring Java
> > semantics to .NET.
> > Async methods in .NET are "T DoSomething()" + "Task<T>
> DoSomethingAsync()"
> > and we should follow this pattern so our API looks familiar to .NET
> > community.
> >
> >
> > > // Line #2
> > > cache.Future().Get();
> >
> > It is cache.GetFuture<X>(). Pay attention to "X". This is very important:
> > user has to specify correct return type according to return type of
> > operation on "Line 1".
> > Very annoying and error prone. There is even a style-checker warning
> about
> > such things.
> >
> >
> > > 2 lines of code instead of one is not a big deal in my view.
> >
> > It is 2 times too much, sometimes even more. Imagine a situation where
> you
> > need to perform multiple async operations:
> >
> > cache.Get(1);
> > var res = await cache.GetFuture<int>().ToTask();
> >
> > compute.Call(new MyCallable(res))
> > var res2 = await compute.GetFuture<string>().ToTask()
> >
> >
> > And with proper async API it can even be a one-liner.
> > var res2 = await compute.CallAsync(new MyCallable(await
> > cache.GetAsync(1)));
> >
> >
> > API is the first thing a programmer sees in the new product. Let's do it
> > right.
> >
> > Thanks,
> >
> > On Fri, Oct 9, 2015 at 7:17 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> > wrote:
> >
> > > 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 <ptupitsyn@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 <
> vozerov@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
> > > >
> > >
> >
> >
> >
> > --
> > --
> > Pavel Tupitsyn
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
>

--001a11440fa23f4ecc0521bce1d7--