[jira] [Commented] (TINKERPOP-1752) Gremlin.Net: Generate completely type-safe methods

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209601#comment-16209601 ] 

ASF GitHub Bot commented on TINKERPOP-1752:
-------------------------------------------

Github user FlorianHockmann commented on the issue:

    https://github.com/apache/tinkerpop/pull/712
  
    I finally found some time to work on this again and fixed the issues mentioned by @jorgebay. However, I left the `Bindings` implementation unchanged despite the problems with concurrent access as it seems to be still the best solution. (I'm of course open for suggestions on how this can be improved.)
    
    I also noticed that my changes broke the `WithoutStrategies` source step as that now correctly expects to get the `Types` of the Strategies to exclude for which Gremlin.Net had no serializer. So I added a serializer that works basically like the respective one in gremlin-python as it also simply creates an object of the `Type` and then this object will be serialized as before. A unit test ensures that all Strategies have a parameterless constructor as we can't serialize their `Type` otherwise.
    Honestly, I was a bit surprised that I had to serialize `Types` by serializing an empty object of that `Type` although the IO docs show that the GraphSON type `g:Class` [can be serialized like this](http://tinkerpop.apache.org/docs/3.3.0/dev/io/#_class):
    ```json
    {
      "@type" : "g:Class",
      "@value" : "java.io.File"
    }
    ```
    but the Gremlin Server couldn't deserialize the Strategy class when I serialized it like this. So is the documentation wrong here? @spmallette: Could you clarify my confusion here?
    Also the IO docs don't mention how `TraversalStrategies` are serialized in general. Should we add that?
    
    The build is currently failing, but that seems to be caused by travis-ci/travis-ci#8607. I built Gremlin.Net locally and executed the tests without any problems.
    
    BTW: Would it make sense to create a separate pull request for `master` or can we simply execute `generate.groovy` later when this is merged from `tp32` into `master`?


> 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)