[
https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15452496#comment-15452496
]
Leifur Halldor Asgeirsson commented on TINKERPOP-1278:
------------------------------------------------------
Whether gremlin-python ultimately uses mixedCase or snake_case methods, I would
like to echo [~aholmber]'s suggestion of using trailing, rather than leading
underscores. It's a pretty strong python convention that objects with a leading
underscore are considered internal and subject to change, so python library
users will tend to avoid them. Also, python tools such as IDEs will often
ignore them for autocompletion, or suggest them last.
> 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
> Fix For: 3.2.2
>
>
> 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)
