[
https://issues.apache.org/jira/browse/TINKERPOP-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17223187#comment-17223187
]
Stephen Mallette commented on TINKERPOP-2461:
---------------------------------------------
starting to think i've already over thought this one. some further points:
1. I didn't think of the perspectives of the other translators (on or off JVM).
Definitely don't want to create situations where we have unique ways to do
things just for the {{GroovyTranslator}} in Java.
2. I think the idea is to try to constrain the open nature of Groovy in doing
translation and make the generated Gremlin conform to the least verbose way of
authoring it - like, assume static imports aside from anonymous traversals
3. I thought reusing {{ImportCustomizer}} infrastructure was smart but I'm not
so sure anymore, given (1) and it just seems to create more complexity than it
is worth. Custom imports can come by way of specific {{TypeTranslator}}
implementations...don't think we should do more there.
4. {{TraversalStrategy}} is kind of a mess. We have a builder for convenience
in Java but a {{create(Configuration)}} for deserialization which
{{GroovyTranslator}} currently uses directly out of programmatic convenience. I
doubt anyone would use that approach in Groovy. A more likely approach would
be the builder OR something like {{create(Map)}}. Would be nice if this was
more unified and constrained in terms of what Gremlin should look like when
these are used.
> Align CoreImports with GroovyTranslator
> ---------------------------------------
>
> Key: TINKERPOP-2461
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2461
> Project: TinkerPop
> Issue Type: Improvement
> Components: translator
> Affects Versions: 3.4.8
> Reporter: Stephen Mallette
> Assignee: Stephen Mallette
> Priority: Major
>
> {{GroovyTranslator}} makes some arbitrary choices about including package
> names in its output. A fair presumption should be that types common to
> Gremlin IO should not need the specificity of the package name (e.g.
> {{UUID}}). I think it would be smart if the {{DefaultTypeTranslator}} used
> {{ImportCustomizer}} instances to control which objects needed package
> specification and which did not. {{ImportCustomizer}} is the same interface
> handed to the {{GremlinGroovyScriptEngine}} and therefore seems to be the
> ideal vehicle to help control {{GroovyTranslator}} output.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
