ASF GitHub Bot commented on TINKERPOP-1919:

Github user FlorianHockmann commented on the issue:

    >I think this is a good change though it doesn't exactly mimic the Java API 
right? there is no until(P) in java - it's until(Predicate), but I guess that 
doesn't really make sense in this GLV to support something like that because we 
can really only serialize values of P across to the server.
    This will be changed with PR #815 that introduces new interfaces, one of 
which is `IPredicate` that we use in Gremlin.Net in places where Java uses 
`Predicate`. My idea was that users could write either predicates in the form 
of lambdas (PR #814) or implement their own predicates which would also require 
their own serialization. Geo-predicates or full-text search are an example 
where implementing custom predicates like this would make sense.
    I'll add something for the upgrade docs. Although it will probably just 
concentrate on cases where users already implemented their own predicates as 
there should be no visible changes for users that only used our predicates. 
`P.gt(1).and(P.lt(3))` can still be called exactly the same way. The only 
difference is that they now get back a `P` object instead of a 

> Gherkin runner doesn't work with P.And() and P.Or() in Gremlin.Net
> ------------------------------------------------------------------
>                 Key: TINKERPOP-1919
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1919
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: dotnet
>    Affects Versions: 3.2.7
>            Reporter: Florian Hockmann
>            Assignee: Florian Hockmann
>            Priority: Major
>             Fix For: 3.2.8, 3.3.2
> Gremlin.Net has split {{P}} into two classes: {{P}} and 
> {{TraversalPredicate}}. This is problematic for the Gherkin runner as it 
> tries to call methods on {{P}} that are only in {{TraversalPredicate}}.
> We can now either let the Gherkin parser try to call {{P}} methods on both 
> classes or we could also just merge those two classes together. I think the 
> reason why they are split was simply that the methods in 
> {{TraversalPredicate}} are written by hand whereas {{P}} is completely 
> generated and I didn't want to write much code inside of Groovy strings that 
> were part of the {{pom.xml}} before [~spmallette] introduced templates for 
> the GLV generation.

This message was sent by Atlassian JIRA

Reply via email to