[
https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549453#comment-15549453
]
ASF GitHub Bot commented on TINKERPOP-1489:
-------------------------------------------
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/450
I did a preliminary review of the code and it looks good. Primarily because
it mimics the structure and content of Gremlin-Python. Ensuring consistency
between all variants is important from a maintainability standpoint.
Here are some concerns:
1. I think we need a `RemoteConnection` implementation. From what I'm
reading, it seems we don't have one.
2. @mbroecheler was pushing for async methods in Gremlin-Java (thus,
"Gremlin"). The idea was to have `Future<V>
Traversal.async(Function<Traversal,V>)`. Thus, to do a "future" `toList()` in
Java, you would do `result = g.V().out().async(Traversal::toList)`. I think we
should do this in Gremlin-Java and then have this same "callback" model used by
Gremlin-JS and thus, not have `one()` and `list()` with callbacks. Does that
make sense?
3. I don't see the Gremlin `ProcessTestSuite` being run. We will need
`Providers` to do so. Please see how this works in Gremlin-Python.
https://github.com/apache/tinkerpop/tree/master/gremlin-python/src/test/java/org/apache/tinkerpop/gremlin/python/jsr223.
4. We will need documentation in `gremlin-variants.asciidoc`.
I suspect we will want to merge this first into an Apache TinkerPop branch
and can nit pick things as I see them before an ultimate merge into `master/`.
For instance, I can do 3 and 4 above if perhaps @jorgebay provides some notes
so I get the important aspects in the documentation.
> Provide a Javascript Gremlin Language Variant
> ---------------------------------------------
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
> Reporter: Jorge Bay
>
> It would be nice to have a Javascript Gremlin Language Variant that could
> work with any ES5 runtime, specially the ones that support
> [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js.
> Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but
> provides [additional
> extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions]
> making modular JavaScript possible. Nashorn should be supported in order to
> run glv tests under the same infrastructure (JDK8).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)