[
https://issues.apache.org/jira/browse/TINKERPOP-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549634#comment-15549634
]
ASF GitHub Bot commented on TINKERPOP-1455:
-------------------------------------------
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/447
If you guys don't mind, I'm going to change the method signatures (the NEW
methods added -- nothing from before changed).
{code}
withStrategy(String, Object...) -> withStrategies(Map<String,Object>...)
withoutStrategy(String) -> withoutStrategies(String...)
{code}
The reason this is smart is:
1. Registering strategies is expensive as it costs a `TraversalSource`
clone and a `TraversalStrategies` sort. This is why doing all strategy
declarations in one method is smart.
2. While creating `Map`s in Java is horrendous, Java users would NOT use
these methods. They would use the Java object version of these methods.
However, for Gremlin-Python, Groovy, JavaScript -- creating maps is natural and
looks good. Also, we don't run into the "multi-key" issues.
Nothing fudamental here, just some asethetics. If you don't object, I will
just do this, update docs, and merge.
> Provide String-based withStrategy()/withoutStrategy() for language variant
> usage
> --------------------------------------------------------------------------------
>
> Key: TINKERPOP-1455
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1455
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant, process
> Affects Versions: 3.2.2
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
>
> Right now {{withStrategies()}} is not supported by Gremlin-Python. Why?
> Because strategies are created via Java and thus you can't do stuff like:
> {code}
> g.withStrategies(SubgraphStrategy.build()...create())
> {code}
> Now, we have strategies that we have made "native" to
> {{GraphTraversalSource}} by way of {{withXXX}}. For example:
> {{withSideEffect()}}, {{withSack()}}, {{withRemote()}}, {{withPath()}}, etc.
> In order to generally support any strategy created by a user for use from a
> language variant, we should support lambda based strategies. E.g.:
> {code}
> g.withStrategies(lambda : "SubgraphStrategy.build()...create()")
> {code}
> Like any other lambda, it is executed server side using the respective
> {{ScriptEngine}}.
> Next, {{withoutStrategies()}} should support {{String...}} so you can do:
> {code}
> g.withoutStrategies("com.stuff.MyStrategy", "com.stuff.MyOtherStrategy")
> {code}
> ..instead of having to pass in the {{Class}} object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
