[
https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16181006#comment-16181006
]
ASF GitHub Bot commented on TINKERPOP-1752:
-------------------------------------------
Github user FlorianHockmann commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/712#discussion_r141104538
--- Diff: gremlin-dotnet/src/Gremlin.Net/Process/Traversal/Bytecode.cs ---
@@ -79,7 +85,77 @@ public void AddSource(string sourceName, params object[]
args)
/// <param name="args">The traversal method arguments.</param>
public void AddStep(string stepName, params object[] args)
{
- StepInstructions.Add(new Instruction(stepName, args));
+ StepInstructions.Add(new Instruction(stepName,
FlattenArguments(args)));
+ Bindings.Clear();
--- End diff --
This is definitely a problem, but do you see a way to fix it?
Unfortunately, I think we have to use `static` here unless we want to create
overloads for each parameter in the Traversal API that takes a `Binding`
instead of the unbound variable which would result in a lot of overloads.
Since [`Bindings` don't seem to improve the performance with
Bytecode](https://lists.apache.org/thread.html/c10baff72e67a8b7728c42b5c4e983a83e82b8f6964b3aa465f0e341@<dev.tinkerpop.apache.org>)
when no lambdas are used which we don't support anyway, we may also remove the
support for `Bindings` altogether from Gremlin.Net. Then we also don't need the
`FlattenArguments` and `ConvertArgument` functions in `Bytecode` which are not
exactly intuitive.
Or if we want to continue supporting them, we could also add a note to the
documentation to make users aware of these concurrency problems with `Bindings`.
> 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: dotnet
> 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)
