Github user FlorianHockmann commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/712#discussion_r141376043
--- 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 --
That's a good point. So we should probably support lambdas. To be honest, I
haven't really looked into what would be necessary to support lambdas. If I'm
not mistaken then we can easily support Python and Groovy lambdas when we add a
dedicated GraphSON serializer for them and probably a class that wraps the
lambda together with its language. Then the steps that take a lambda would
simply accept an object of that class in Gremlin.Net. I can create a separate
ticket for this when we agree that we want to support them.
When we want to support lambdas then we should also support `Bindings`.
That leaves us with the question of whether we find a better implementation
that doesn't suffer from the concurrency problems @jorgebay mentioned or if the
current implementation in this pull request is acceptable.
Apart from that, shouldn't we clarify the section in the documentation
about bindings? It currently states for example [for
gremlin-python](http://tinkerpop.apache.org/docs/current/reference/#_bindings):
> If a traversal is going to be executed repeatedly, but with different
parameters, then bindings should be used.
because:
> translation and compilation can be skipped as the previously compiled
version should be cached
which is only true when a lambda is used if I understood it correctly.
---
