[jira] [Created] (TINKERPOP-1340) docs do not state at what version an API was introduced (or deprecated)

[Jason Plurad (JIRA)]

Jason Plurad created TINKERPOP-1340:
---

 Summary: docs do not state at what version an API was introduced 
(or deprecated)
 Key: TINKERPOP-1340
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1340
 Project: TinkerPop
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.1.2-incubating, 3.2.0-incubating
Reporter: Jason Plurad
Priority: Trivial
 Fix For: 3.1.3, 3.2.1


An all-to-common problem for new developers coming to the TinkerPop is figuring 
out which APIs work against the graph they are using. Since TinkerPop is ahead 
of many graph implementation out there (Titan/TP 3.0.1, Stardog/TP 3.0.2, 
Blazegraph/TP 3.1.0 -- kudos to Sqlg and Unipop for TP 3.2.0!), it's really 
important that developers know which APIs in the current docs are valid. 
Ideally the developers would go directly to that version of the TP docs, but 
that doesn't always happen thanks to Google.

I propose doc updates on each Graph Traversal Step in the [reference 
docs|http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps] 
and in the javadocs (on 
[__.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/__.html]
 and on specific step implementations, i.e. 
[AddEdgeStep.java|http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/step/map/AddEdgeStep.html]).

It should state the specific version (3.y.z) the API was introduced or 
deprecated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1320) GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical

[Jason Plurad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Plurad updated TINKERPOP-1320:

Fix Version/s: 3.2.1
   3.1.3

> GremlinGroovyScriptEngineFileSandboxTest throws error: URI is not hierarchical
> --
>
> Key: TINKERPOP-1320
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1320
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> This is similar to TINKERPOP-1317. The differences here are
> * The {{TestHelper.generateTempFileFromResource()}} call to load the resource 
> is happening from the {{public static void init()}} method before a graph 
> instance is available.
> * A reference to {{GremlinGroovyScriptEngineFileSandboxTest.class}} is still 
> required to located the {{sandbox.yaml}} found in the {{gremlin-test.jar}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330495#comment-15330495
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/330
  
ok - it wasn't a big deal - i could have just merged your stuff into a 
local branch and tested.


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #330: TINKERPOP-1319: several FeatureRequirement annotations...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/330
  
ok - it wasn't a big deal - i could have just merged your stuff into a 
local branch and tested.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330486#comment-15330486
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/330
  
@spmallette because I find myself in GitHub more often than ASF git. I'll 
close this and reopen a new PR.


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1319) several FeatureRequirement annotations are incorrect in gremlin-test

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330487#comment-15330487
 ] 

ASF GitHub Bot commented on TINKERPOP-1319:
---

Github user pluradj closed the pull request at:

https://github.com/apache/tinkerpop/pull/330


> several FeatureRequirement annotations are incorrect in gremlin-test
> 
>
> Key: TINKERPOP-1319
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1319
> Project: TinkerPop
>  Issue Type: Bug
>  Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Assignee: Jason Plurad
>Priority: Minor
> Fix For: 3.1.3, 3.2.1
>
>
> Several {{@FeatureRequirement}} annotations are incorrect in these 
> {{gremlin-test}} tests
> * EdgeTest.java
> * FeatureSupportTest.java
> * GraphTest.java
> * PropertyTest.java
> * VertexPropertyTest.java
> * VertexTest.java
> I'll submit a patch for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #330: TINKERPOP-1319: several FeatureRequirement annotations...

[pluradj]

Github user pluradj commented on the issue:

https://github.com/apache/tinkerpop/pull/330
  
@spmallette because I find myself in GitHub more often than ASF git. I'll 
close this and reopen a new PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #330: TINKERPOP-1319: several FeatureRequirement anno...

[pluradj]

Github user pluradj closed the pull request at:

https://github.com/apache/tinkerpop/pull/330


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #333: if there is no edge label in the GraphML file, ...

[spmallette]

Github user spmallette commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/333#discussion_r66994055
  
--- Diff: CHANGELOG.asciidoc ---
@@ -1245,6 +1245,7 @@ TinkerPop 3.0.0.M2 (Release Date: September 23, 2014)
 * Moved `GiraphGraph.getOutputGraph()` to `GiraphHelper`.
 * Changed `GIRAPH_GREMLIN_HOME` to `GIRAPH_GREMLIN_LIB` to reference 
directory where jars are to be loaded.
 * Updated README with release instructions.
+* if there is no edge label in the GraphML file, then use Edge.DEFAULT
--- End diff --

i was going to fix that - i probably should have noted that in my comments


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #333: if there is no edge label in the GraphML file, ...

[okram]

Github user okram commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/333#discussion_r66993744
  
--- Diff: CHANGELOG.asciidoc ---
@@ -1245,6 +1245,7 @@ TinkerPop 3.0.0.M2 (Release Date: September 23, 2014)
 * Moved `GiraphGraph.getOutputGraph()` to `GiraphHelper`.
 * Changed `GIRAPH_GREMLIN_HOME` to `GIRAPH_GREMLIN_LIB` to reference 
directory where jars are to be loaded.
 * Updated README with release instructions.
+* if there is no edge label in the GraphML file, then use Edge.DEFAULT
--- End diff --

Why is this in the MX release section? Also, please capitalize "If" like 
all other CHANGELOG update.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (TINKERPOP-1328) Provide [gremlin-python] as an code executor in docs

[Daniel Kuppitz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kuppitz reassigned TINKERPOP-1328:
-

Assignee: Daniel Kuppitz

> Provide [gremlin-python] as an code executor in docs
> 
>
> Key: TINKERPOP-1328
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1328
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
> Fix For: 3.2.1
>
>
> We currently support {{[gremlin-groovy]}} and 
> {{[gremlin-groovy,modern]}}-style code block annotations. It would be good to 
> also support {{[gremlin-python]}} and {{[gremlin-python,modern]}}. Likewise, 
> ensure a generalization for the future when {{gremlin-ruby}} and 
> {{gremlin-php}} are added.
> Gremlin-Python source can be evaluated using Groovy and the Jython 
> ScriptEngine. Suppose the following code block:
> {code}
> [gremlin-python,modern]
> g.V().out().name
> {code}
> *GROOVY*
> First, assume the following startup code that should be evaluated once and 
> only once into the Gremlin-Groovy script engine.
> {code}
> import javax.script.ScriptEngineManager
> import javax.script.SimpleBindings
> loader = new URLClassLoader(new 
> File("/Applications/jython-2.7.0/jython.jar").toURI().toURL()) // JYTHON_PATH 
> is better
> jython = new ScriptEngineManager(loader).getEngineByName("jython")
> jython.eval("import sys");
> jython.eval("sys.path.append('/Users/marko/software/tinkerpop/gremlin-variant/src/main/jython/gremlin_python')");
>  // PYTHON_PATH is better
> jython.eval("from gremlin_python import *");
> jythonBindings = new SimpleBindings();
> jythonBindings.put("g", jython.eval("PythonGraphTraversalSource('g')"));
> jython.getContext().setBindings(jythonBindings, 
> javax.script.ScriptContext.GLOBAL_SCOPE);
> {code}
> *The above requires that a global variable exist to where Jython is installed 
> as well as to where Gremlin-Python is installed. Though, for the latter, you 
> will simply be able to use {{pip}} to install dynamically ({{PYTHON_PATH}}) 
> is set to the location of Gremlin-Python.*
> From there, the code block above would be evaluated as:
> {code}
> g = TinkerGraphFactory.createModern().traversal()
> Eval.me("g", g, jython.eval("g.V().out().name").toString())
> {code}
> This looks as follow:
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> Eval.me("g", g, jython.eval("g.V().out().name").toString())
> ==>lop
> ==>vadas
> ==>josh
> ==>ripple
> ==>lop
> ==>lop
> {code}
> And thats that...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329563#comment-15329563
 ] 

stephen mallette commented on TINKERPOP-1278:
-

I think that we should basically rule option 1 because this minus:

> minus Every XXXTraversal will need to have a ScriptXXXTraversal 
> implementation. For GraphTraversal, this was a copy/paste nightmare.

sound like a bad way to go. As I read the end of option 3 i was already 
thinking about your last bit where you would delegate traversal step adding to 
the strategy. We could probably do better than a giant {{switch}} embedded in 
the strategy to implement that. Maybe it's some form of Command Pattern where 
you would have this base class that lets you register a {{AddStepCommand}} for 
each available step name. Then you just lookup the {{AddStepCommand}} from a 
{{Map}} of commands? It leads to lots of small classes (which could probably 
just be inner classes of {{AddStepCommand}} interface) but at least then it's 
more modular and each individual command would be easily testable. Maybe we 
even get lucky and the same command might be useful across multiple step 
additions

> Implement Gremlin-Python and general purpose language variant test 
> infrastructure
> -
>
> Key: TINKERPOP-1278
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1278
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> As discussed on dev@...
> Apache TinkerPop should provide, out-of-the-box, at least 3 Gremlin language 
> variants. It would be cool if these were:
> * Python (Mark Henderson)
> * PHP ([~PommeVerte])
> * Ruby (?[~okram])
> I think each of these should be generated using the reflection-model 
> presented in 
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/.
>  Moreover, on every {{mvn clean install}}, the code for these variants is 
> generated.
> Given the desire to separate language variants from language drivers, I think 
> that a language driver for each variant above should be "plugable." Moreover, 
> we should provide one driver implementation for each -- simple GremlinServer 
> REST.
> {code}
> gremlin-variants/
>   gremlin-ruby/
> gremlin_ruby.rb
> gremlin_ruby_rest_driver.rb
>   gremlin-php/
> Gremlin_PHP.php
> Gremlin_PHP_REST_Driver.php
>   gremlin-python/
> gremlin-python.py
> gremlin-python-rest-driver.py
> {code}
> Next, each variant implementation should be testable. This is PAINFUL if we 
> have to implement each {{g_V_out_repeatXasXaXX}} test case in 
> {{ProcessXXXSuite}}. Perhaps some RegEx transducer magic could be used to 
> convert all those tests from Gremlin-Java to the respective host language? 
> However, even if we do that, we still have the problem of how to test the 
> returned results. 
> I think what we should test the returned results using the JVM. For instance, 
> JRuby, Jython, JPHP (does it exist?). If we do this, we will save ourselves a 
> massive headache. All we have to do is create a {{GraphProvider}} that uses 
> {{TinkerGraph}} and whose {{TraversalSource}} is some sort of wrapper around 
> reflection-generated Ruby (e.g.).
> {code}
> g.V.out_e("knows") // returns a Ruby iterator
> {code}
> That Ruby iterator should be converted to a Java iterator and then the 
> {{ProcessXXXSuite}} can verify the results.
> With this, most everything is reflectively constructed.
> {code}
> gremlin_ruby.rb // generated via Java reflection
> gremlin_ruby_rest_driver.rb // manually coded
> match_test.rb   // generated via RegEx transducer
> has_test.rb // generated via RegEx transducer
> ...
> RubyGraphProvider.java// manually coded
> RubyProcessStandardSuite.java // manually coded
> RubyProcessComputerSuite.java // manually coded
> {code}
> Thus, the testing data flow would be:
> {code}
> MatchTest.Traversals.java --transducer-> match_test.rb
> match-test.rb --REST--> GremlinServer
> GremlinServer --GraphSON-->match-test.rb
> GraphSON --JRuby/GraphSONReader-->Java objects
> Java objects --JRuby-->MatchTest.java 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #333: if there is no edge label in the GraphML file, then us...

[PommeVerte]

Github user PommeVerte commented on the issue:

https://github.com/apache/tinkerpop/pull/333
  
Simple enough, looks good VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop issue #333: if there is no edge label in the GraphML file, then us...

[twilmes]

Github user twilmes commented on the issue:

https://github.com/apache/tinkerpop/pull/333
  
Looks good.  Thanks for the contribution @SergeVil.

VOTE: +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TINKERPOP-1339) Make Step.id() generation faster and simpler

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1339:
-

 Summary: Make Step.id() generation faster and simpler
 Key: TINKERPOP-1339
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1339
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.0-incubating
Reporter: Marko A. Rodriguez


There is a class called {{StepPosition}} that is smart about creating unique 
ids for steps. Unique, deterministic creation of step ids is important. 
However, what we have now is expensive. When I original did this, I created an 
string ID scheme where you could find your location in the traversal, by the id 
"[0:[1:[2:3]]]" (first step of the root traversal is a traversal parent -- the 
third step of the second traversal). Why I did it like this I don't know why??! 
... Instead, I think we can make things both faster and simpler:

1. Change {{Step.id()}} to an integer, not a String.
2. Step id labeling is simply walking the traversal tree in a deterministic 
depth first manner and incrementing a {{nextId++}} counter.

We can do 2 without 1 and it would not be a breaking change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Another "Incubator" change.

[Stephen Mallette]

we dont' have any releases yet outside of incubator so it is my
understanding that the archive wont' reflect any. note that our release
directory however is in place and ready to go:

https://dist.apache.org/repos/dist/release/tinkerpop/

i think that when we add our first non-incubator release there, it will
mirror to archive and we'll see stuff there.

On Tue, Jun 14, 2016 at 8:29 AM, Marko Rodriguez 
wrote:

> Hi,
>
> On the webpage, an outstanding “incubator” change I see is:
>
> http://archive.apache.org/dist/incubator/tinkerpop/ <
> http://archive.apache.org/dist/incubator/tinkerpop/>
>
> The above URL should be:
>
> http://archive.apache.org/dist/tinkerpop/ <
> http://archive.apache.org/dist/tinkerpop/>
>
> …but as it stands, that doesn’t exist.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
>
>

Another "Incubator" change.

[Marko Rodriguez]

Hi,

On the webpage, an outstanding “incubator” change I see is:

http://archive.apache.org/dist/incubator/tinkerpop/ 


The above URL should be:

http://archive.apache.org/dist/tinkerpop/ 


…but as it stands, that doesn’t exist.

Thanks,
Marko.

http://markorodriguez.com

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[Marko A. Rodriguez (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329388#comment-15329388
 ] 

Marko A. Rodriguez commented on TINKERPOP-1278:
---

So in branch {{TINKERPOP-1278}} we have 2 different ways of doing this 
implemented and I think a third (yet unimplemented) way may be the best. I will 
describe all three models with their +/- so people can help decide which model 
we should go with. First, note that all three models make use of a new 
construct called a {{Translator}}. In short, a {{Translator}} wraps a 
{{StringBuilder}} and for each {{traversal.x(y,z)}} call, 
{{Translator.addStep(traversal, "x", y, z)}} is called. In essence the 
translator is able to take calls in one Gremlin variant and convert them to 
calls in another Gremlin variant.

1. {{ScriptXXXTraversal}} and {{ScriptXXXTraversalSource}}

{{ScriptGraphTraversal}} implements all the methods of {{GraphTraversal}}, but 
instead of {{addStep(new BlahStep())}}, it calls {{Translator.addStep(stepName, 
Object... stepArguments)}}. When {{applyStrategies()}} is called (i.e. the 
traversal is compiled), the {{Translator.getScriptEngine()}} is used to compile 
the internal {{Translator.getTraversalScript()}} and the result of the 
compilation is added to the {{ScriptGraphTraversal}} and thus, the 
{{ScriptGraphTraversal}} has implemented steps and is ready to execute.

*plus* Translation is decoupled from {{DefaultGraphTraversal}} and thus, an 
entirely separate class space.
*minus* Every {{XXXTraversal}} will need to have a {{ScriptXXXTraversal}} 
implementation. For {{GraphTraversal}}, this was a copy/paste nightmare.
*minus* {{ScriptGraphTraversalSource}} is required and thus, this is NOT a 
{{TraversalStrategy}} but a new {{TraversalSource}} -- 
{{graph.traversal(PythonTranslator.of("g"))}}.

2. {{TranslationStrategy implements CreationStrategy}} 

In this model, there is a new type of {{TraversalStrategy}} called a 
{{CreationStrategy}} whose sort order comes before {{DecorationStrategy}}. 
Along with {{apply(traversal)}} method, creation strategies also have a 
{{addStep(stepName,stepArguments...)}} method as well as a {{getTranslator()}} 
method. This means that every {{GraphTraversal}} method has the following form:

{code}
public default GraphTraversal out(final String... edgeLabels) {
  TraversalHelper.addStepToCreationStrategies(this.asAdmin(), "out", 
edgeLabels);
  return this.asAdmin().addStep(new VertexStep<>(this.asAdmin(), Vertex.class, 
Direction.OUT, edgeLabels));
}
{code}

Finally, {{TranslationStrategy.apply()}} does like {{RemoteStrategy}} does and 
simple compiles the script and inserts the steps into the traversal.

*plus* {{CreationStrategy}} is like an interceptor and we could reuse this 
construct in other areas.
*minus* If you are doing translation, you are also constructing the traversals 
in the host language (wasted memory/clock cycles).
*minus* {{CreationStrategy}} is sorta like a {{TraversalStrategy}} but has more 
methods.
*plus* Everyone's implementation of {{XXXTraversal}} has all the machinery for 
translation. No need for a parallel {{ScriptXXXTraversal}} implementation to 
maintain.

3. {{Traversal.setTranslator(translator)}} 

If we make {{Translator}} core to {{Traversal}} then we would have the benefits 
of the two above without the drawbacks.

{code}
public default GraphTraversal out(final String... edgeLabels) {
  if(null != this.translator) {
this.translator.addStep(this.asAdmin(), "out", edgeLabels);
return this;
  } else
return this.asAdmin().addStep(new VertexStep<>(this.asAdmin(), 
Vertex.class, Direction.OUT, edgeLabels));
}
{code}

*plus* You either translate or your construct -- no wasted memory/clock cycles.
*minus* {{Translator}} is now a "new concept" parallel with 
{{TraversalStrategies}} and {{TraversalSideEffects}}.

-

Finally, I really do like {{CreationStrategy}}, but if we do it, then I think 
that instantiating steps and adding them to the traversal would actually be a 
{{CreationStrategy}}. For instance:

{code}
public default GraphTraversal out(final String... edgeLabels) {
  TraversalHelper.addStepToCreationStrategies(this.asAdmin(), "out", 
edgeLabels);
  return this;
}
{code}

That is, there would be a {{AddStepStrategy}} which would 
{{traversal.addStep(new VertexStep<>(this.asAdmin(), Vertex.class, 
Direction.OUT, edgeLabels))}}! If you wanted to translate only, then you would 
remote {{AddStepStrategy}} and add {{TranslationStrategy}} CraZy. The 
drawback of this is that {{AddStepStrategy}} would look something like this:

{code}
switch stepName
  case "out":
traversal.addStep(new VertexStep<>(this.asAdmin(), Vertex.class, 
Direction.OUT, (String[]) args[0]));
break;
  case "map":
...
  case "fold":
   ...
  case "groupCount":
   ...
{code}

> Implement Gremlin-Python and general purpose language variant test 
>