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

Reply via email to