@aholmber - Regarding naming, while methods typically have lowercase names separated with underscores, PEP 8 does suggest that "mixedCase is allowed only in contexts where that's already the prevailing style". While this typically refers to backwards compatibility, you see mixed case in libraries that provide bridges to other languages...the example that comes to mind is PyObjC. I wonder if this is an example where using mixed case is acceptable in order to give gremlin-python the same "feel" as gremlin...thoughts?
On Tue, Aug 30, 2016 at 2:39 PM, stephen mallette (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449778#comment-15449778 > ] > > stephen mallette commented on TINKERPOP-1278: > --------------------------------------------- > > [~stamhankar999] thanks for your thoughts on the testing aspects of things. i > think we have some work to do before we can call the testing model completely > settled for all GLVs. I suspect some changes will occur. I think we need a > good mix of native tests as well as those that can be executed via the > process suites. We will try to come to a full understanding of that model for > 3.3.x. > > [~aholmber] i remember your commit comment. i think that happened when > [~okram] was away on vacation. since he wrote the code generation stuff for > that, perhaps he'd be best to have a look and address your concerns. > >> 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) -- David M. Brown R.A. CulturePlex Lab, Western University
