[ https://issues.apache.org/jira/browse/TINKERPOP-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17947109#comment-17947109 ]
ASF GitHub Bot commented on TINKERPOP-3055: ------------------------------------------- spmallette commented on code in PR #3099: URL: https://github.com/apache/tinkerpop/pull/3099#discussion_r2058956915 ########## gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java: ########## @@ -177,6 +178,7 @@ static final class GraphSONModuleV3 extends GraphSONModule { put(OrP.class, "P"); put(P.class, "P"); put(TextP.class, "TextP"); + put(TraversalStrategyProxy.class, "TraversalStrategy"); Review Comment: yes, i agree with all that. i figured that 4.x will wholly resolve this mess, so 3.x may just have to be a little ugly. > withoutStrategies() mechanism in programming languages for providers > -------------------------------------------------------------------- > > Key: TINKERPOP-3055 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3055 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, go, javascript, process, python > Affects Versions: 3.7.1 > Reporter: Stephen Mallette > Priority: Major > > {{withoutStrategies()}} is in the grammar for TINKERPOP-2862. That change did > not address its accessibility for provider strategies in language variants > very well. As the syntax requires a {{Class}} (and for the grammar, a > registered strategy class) you may not have that reference in a language > variant. Users could create dummy classes as the grammar works on simple > name, but that's not especially nice. Otoh, most users shouldn't be tinkering > with strategies so perhaps that's ok? It could be inconvenient for notebook > users and similar tools though to create the dummy. A simple alternative > could just be a {{withoutStrategies(String...)}} but that's not particularly > nice. Other ideas? > needs a general look at all strategy construction across all languages: > 1. check if the strategy construction makes sense in terms of types and > syntax in each language > 2. watch out for wrong types being parsed into {{Configuration}} which can > lead to weird looking errors. > 3. are there adequate tests to validate all our syntax is working. we > technically need to test every strategy configuration options as those > corners are where bugs can hide. > 4. double check {{List}} vs {{Set}} syntax because {{Set}} might be preferred > but a lot of folks will reach for {{[ ]}} just out of habit....do we want > them failing for that? can we ease the type there without losing {{Set}} in > type safe languages? -- This message was sent by Atlassian Jira (v8.20.10#820010)