[
https://issues.apache.org/jira/browse/TINKERPOP-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-3055.
---------------------------------------
Fix Version/s: 4.0.0
3.8.0
Assignee: Stephen Mallette
Resolution: Done
> 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
> Assignee: Stephen Mallette
> Priority: Major
> Fix For: 4.0.0, 3.8.0
>
>
> {{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)
