[
https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16163142#comment-16163142
]
ASF GitHub Bot commented on TINKERPOP-1752:
-------------------------------------------
GitHub user FlorianHockmann opened a pull request:
https://github.com/apache/tinkerpop/pull/712
TINKERPOP-1752: Gremlin.Net: Generate completely type-safe methods
https://issues.apache.org/jira/browse/TINKERPOP-1752
All steps are now (basically) type-safe and the original argument names
from Gremlin-Java are used. However, we currently don't support some Java types
like `Comparator`. Those were simply replaced by `object` until we find a
better solution. A problem with this workaround is that some overloads from
Gremlin-Java are not supported in Gremlin.Net as they would result in the same
method signature.
The implementation of `Bindings` is now basically the same as in
Gremlin-Java. This change was necessary as `Bindings.Of()` can no longer return
a `Binding` object
These changes also revealed a bug in the tests where the
`WithoutStrategies` source step was called with objects of strategies instead
of just with their types. However, `WithoutStrategies` still can't work right
now as a GraphSON serializer is missing for `Type`.
The `Group` step for example looks now like this:
```cs
/// <summary>
/// Adds the group step to this <see cref="GraphTraversal{SType,
EType}" />.
/// </summary>
public GraphTraversal< S , IDictionary<K, V> > Group<K, V> ()
{
Bytecode.AddStep("group");
return Wrap< S , IDictionary<K, V> >(this);
}
/// <summary>
/// Adds the group step to this <see cref="GraphTraversal{SType,
EType}" />.
/// </summary>
public GraphTraversal< S , E > Group (string sideEffectKey)
{
Bytecode.AddStep("group", sideEffectKey);
return Wrap< S , E >(this);
}
```
So this should also solve
[TINKERPOP-1751](https://issues.apache.org/jira/browse/TINKERPOP-1751) that
mentioned the missing overload for `Group` that returns `IDictionary<K, V>`.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1752
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/712.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 #712
----
commit 05851764f1e20abb1a82b7d662b4681d602a5774
Author: Florian Hockmann <[email protected]>
Date: 2017-08-17T20:57:07Z
Make Gremlin.Net graph traversal API type-safe
All steps are now type-safe and the original argument names from
Gremlin-Java are used. However, we currently don't support some Java
types like Comparator. Those were simply replaced by object until we
find a better solution. A problem of this workaround is that some
overloads from Gremlin-Java are not supported in Gremlin.Net as they
would result in the same method signature.
This required to change how Bindings work as Bindings.Of() can no longer
return a Binding object. The implementation for Bindings is now
basically the same as in Gremlin-Java.
This also revealed a bug in the tests that called the WithoutStrategies
source step with objects of strategies instead of just with their types.
However, WithoutStrategies still can't work right now as a GraphSON serializer
is missing for Type.
----
> Gremlin.Net: Generate completely type-safe methods
> --------------------------------------------------
>
> Key: TINKERPOP-1752
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1752
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
> Affects Versions: 3.2.5
> Reporter: Florian Hockmann
> Priority: Minor
>
> Currently the generated traversal methods in Gremlin.Net take {{params
> object[] args}} as an argument which allows the user to provide an arbitrary
> number of arguments with any type. While this makes the generation rather
> simple, it doesn't tell the user which arguments are actually valid so users
> can submit completely invalid traversals like:
> {code}
> g.V(1).AddE(1234, "invalidArgument2").Next()
> {code}
> Type-safe methods could also use the original argument names to tell users
> something about what kind of values the methods expect. Consider for example
> the following method signatures for the C# step {{AddE}} that are basically a
> 1:1 representation of the original Java {{addE}} step:
> {code}
> public GraphTraversal< S , Edge > AddE (Direction direction, string
> firstVertexKeyOrEdgeLabel, string edgeLabelOrSecondVertexKey, params object[]
> propertyKeyValues);
> public GraphTraversal< S , Edge > AddE (string edgeLabel);
> {code}
> Implementing this should make TINKERPOP-1725 obsolete and also resolve
> TINKERPOP-1751.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
