[
https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151854#comment-16151854
]
Florian Hockmann commented on TINKERPOP-1752:
---------------------------------------------
I just fixed the problems mentioned above. Unfortunately, I found two new
problems:
1) Bindings don't work at the moment. The reason is that {{Bindings.Of()}}
returns a {{Binding}} object instead of the bound value itself. This cannot
work anymore as the steps don't accept arguments of type {{Binding}}. So we
need to rework the way bindings work in Gremlin.Net. In the end it will be
probably very similar to Gremlin-Java which stores the bingings in a {{static}}
variable.
2) Steps that have a {{params}} array argument currently crash when the array
is empty, e.g., when {{HasLabel}} is called with just one label (its arguments
are: {{string label, params string[] otherLabels}}). The reason is that the
empty array will be sent to the server which doesn't expect this. So we have to
add a check for such a {{params}} array and only pass it to the {{Bytecode}} if
it actually contains arguments.
> 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)
