I've been thinking a bit about TraversalStrategy declarations. There are
really two forms:
1. an easy no configuration option which is typically a singleton and is
just created by instance() like ReadOnlyStrategy.instance()
2. a more complex option that uses builder pattern to construct the
traversal with build()...create() as in
ReservedKeysVerificationStrategy.build().reservedKeys(new
HashSet<String>(){{ add("id");}})
The Builder pattern is kinda neat in that it's quite explicit API and looks
familiar in Java. It doesn't really translate though to other languages so
well, aside from C# perhaps. We've already gone to constructors with named
arguments in other languages like Python and Javascript which is much more
succinct. That leaves Groovy a bit on its own and while Groovy could
probably follow the Java path it doesn't look quite right in practice
(which means it doesn't really follow the premise of what variants are
about):
g.withStrategies(ReservedKeysVerificationStrategy.build().reservedKeys(['id']
as Set).create()).V()
or more groovy-er
g.withStrategies(new
ReservedKeysVerificationStrategy(reservedKeys:['id'])).V()
I think about these things because I've been looking at Translator
implementations lately and it is important that they generate the canonical
form of their variant so that we have shared consistency for what Gremlin
is in each language.
Finally, consider that Groovy scripts are still a prevalent way of shipping
Gremlin around. I've often thought they might die out but they remain
persistent especially with REST APIs and I imagine even TinkerPop 4 won't
be able to dislodge them. If so, Gremlin in Groovy is likely to be the
canonical string representation of Gremlin.
For more random thoughts see:
https://issues.apache.org/jira/browse/TINKERPOP-2461
Anyone happen to have any thoughts on this matter?
