[
https://issues.apache.org/jira/browse/TINKERPOP-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342165#comment-16342165
]
ASF GitHub Bot commented on TINKERPOP-1854:
-------------------------------------------
GitHub user FlorianHockmann opened a pull request:
https://github.com/apache/tinkerpop/pull/792
TINKERPOP-1854 Add Lambdas for Gremlin.Net
https://issues.apache.org/jira/browse/TINKERPOP-1854
Since we don't have a way to parse C# lambdas on server side, this PR
simply allows to send lambdas in other languages with Gremlin.Net:
- For a Groovy lambda: `Lambda.Groovy("it.get().value('name').length()")`
- and for a Python lambda: `Lambda.Python("lambda x:
len(x.get().value('name'))")`
All features are passing now - no features are ignored any more. Therefore
I also removed the functionality to ignore features in Gremlin.Net. (I hope
that we won't need to ignore any features in Gremlin.Net in the future, but if
we have to then it shouldn't be an issue to get this functionality back.)
Unfortunately, it's not possible to use this new `Lambda` type for
arguments in the traversal API due to the fact that in Java the type `Function`
would correspond to this type, but Java also allows to pass for example the
enum `T` as a `Function` because `T` implements `Function<Element, Object>`. So
we cannot simply replace all `Function` types from Gremlin-Java with `Lambda`
in Gremlin.Net as that would break for example this step:
```
public default <U> GraphTraversal<S, E> by(final Function<U, Object>
function,
final Comparator comparator)
```
that can be called like this: `by(T.value, Order.incr)` which wouldn't be
possible when the first argument would only take a `Lambda` in Gremlin.Net.
(Luckily, I found this thanks to a Gherkin scenario that makes exactly this
call.)
So, currently all arguments where a lambda is possible simply expect an
`object`.
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1854
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/792.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #792
----
commit 976079d6e7ded8b7f71605adba102ce530a4ecde
Author: Florian Hockmann <fh@...>
Date: 2018-01-27T13:41:28Z
TINKERPOP-1854 Add Lambdas for Gremlin.Net
All features are passing now (no ignored ones any more).
----
> Support lambdas in Gremlin.Net
> ------------------------------
>
> Key: TINKERPOP-1854
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1854
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Affects Versions: 3.3.0, 3.2.6
> Reporter: Florian Hockmann
> Assignee: Florian Hockmann
> Priority: Major
>
> Gremlin.Net should support lambdas. We already discussed this in [the pull
> request for TINKERPOP-1752|https://github.com/apache/tinkerpop/pull/712].
> Here is what [~spmallette] said over there:
> {quote}
> Any reason we don't support lambdas? Even if .NET can't support them natively
> for some reason wouldn't we minimally support the ability to pass a
> python/groovy/etc lambda? it's kinda weird that way, but i think back to the
> point that kuppitz made on the dev list the other day where he stated that he
> doesn't always find a way out of using lambdas in production systems he works
> on - so ultimately users will need that kind of capability i think.
> {quote}
> C# lambdas would require some kind of C# parser on the server side, so at
> least in the beginning a way to send lambdas from already supported languages
> in Gremlin.Net should be enough.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
