[ https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16179213#comment-16179213 ]
ASF GitHub Bot commented on TINKERPOP-1752: ------------------------------------------- Github user jorgebay commented on a diff in the pull request: https://github.com/apache/tinkerpop/pull/712#discussion_r140818483 --- 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 -- Even though `Bindings` is based on a `ThreadLocal<T>` instance, I think the implementation is not thread-safe. For example: Multiple tasks executed serially on the same thread, modifying the same bindings dictionary. Besides not being thread-safe, it doesn't support defining a binding on 1 thread and adding the step on another, sample: ```csharp // thread 1 // define bindings Bindings.Instance.Of(/* */); await SomeUnRelatedTask(); // thread 2 // Do something with that binding g.V()/**/; ``` > 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)