[
https://issues.apache.org/jira/browse/TINKERPOP-2461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17223843#comment-17223843
]
Stephen Mallette commented on TINKERPOP-2461:
---------------------------------------------
More thoughts on item 4 in the last comment - I don't think there is any other
part of Gremlin that relies on a third-party class as a primary input which
makes {{create(Configuration)}} a bit weird. We do use {{Configuration}} for
things but not really in Gremlin the language itself. I think we considered
{{create(Configuration)}} to be "hidden" (though it is {{public}}) as we had
nice builder methods for java users. Another interesting side-point is that we
convert in and out of {{Configuration}} to {{Map}} in {{JavaTranslator}} which
is the primary place where this {{create(Configuration)}} matters. I'm not
really seeing where the features of {{Configuration}} actually come into play
at all. In fact, it seems to get in the way.
I was thinking that the direct approach would be to deprecate usage of
{{Configuration}} somehow and introduce {{Map}} but in a way neither make sense
for the Java developer really as the {{Builder}} would be their approach. I
wonder if the same would be said for Groovy - like, which of the following is
more Groovy:
{code}
g.withStrategies(ReservedKeysVerificationStrategy.build().reservedKeys(['id']
as Set).create()).V()
// or
g.withStrategies(new ReservedKeysVerificationStrategy(reservedKeys:['id'])).V()
{code}
Arguably the latter. It makes me wonder if there is a reason to carefully align
Java and Groovy since our goal is to try to make each variant comfortable in
each language. On the flip side we may find users confused with Groovy examples
if they do not have accompanying Java versions.
> 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)
