I would draw the line at the native language's understanding of future/promise, which are generally represented in most languages i'm aware of. The specifics of CompletableFuture do not have to be maintained. I suppose we could consider it sugar specific to the GLV.....not sure one way or the other right now.
On Sat, Oct 8, 2016 at 8:39 AM, Robert Dale <[email protected]> wrote: > I think it's outside of gremlin's scope and may be better served by > native facilities. It seems like sugar. In Java this saves not even > one line of code. It looks an additional requirement for GLVs to > implement possibly using a syntax that is non-native thus additional > to learn. But the GLV folks will have to speak to that. Even if so, > where do you draw the line? Until you've reimplemented all of > CompletableFuture? I already use java's and spring's async > facilities so I would not likely use this. > > On Sat, Oct 8, 2016 at 7:08 AM, Stephen Mallette <[email protected]> > wrote: > > Please note the discussion on adding a terminal future method to > Traversal > > on this JIRA ticket: > > > > https://issues.apache.org/jira/browse/TINKERPOP-1490 > > > > If you have comments, please add them there. > > > > -- > Robert Dale >
