[GitHub] tinkerpop issue #852: TINKERPOP-1944 Export DriverRemoteConnection
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/852 VOTE +1 ---
[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/695 All good to me! VOTE +1 ---
[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV
Github user jbmusso commented on the issue:
https://github.com/apache/tinkerpop/pull/695
According to https://github.com/petkaantonov/bluebird/issues/1026, users
should be able to just patch the global `Promise` object in their application
with:
```javascript
global.Promise = require("bluebird");
```
I am unsure about other Promise libraries but I believe this approach
should work as long as they're Promise/A+ standard compliant. Maybe we could
also give it more thoughts and see for other ways to handle this in a future
release, but I think it's worth making the code simpler at this point. I also
feel it can/should be done at the application level.
For Traversal methods, I didn't think about IDEs and you're absolutely
right about code completion. I think your proposed approach with
`callOnEmptyTraversal` works best. This makes me think that I'm pretty sure
people will want typed traversals with TypeScript or FlowType soon (thinking
about https://github.com/DefinitelyTyped/DefinitelyTyped here for example).
---
[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/695 Finally found some time. Wew. Well, this PR is very well crafted - well done! My comments are only minor: * About `utils.toPromise` - if I understand you well, you want a dual callback/promise API for most async functions? * In `graph-traversal.js`, most methods of `GraphTraversalSource` and `GraphTraversal` and function attached to `statics` could maybe be dynamically created from an array of method names and dynamically added to these classes/object. I donât know what would be the performance implication of this, but I donât think there should be any unless V8 really canât figure out whatâs going on when parsing that file. Hopefully it's smart and figures out that the class is not changing. Thatâd lower the file size and help maintainability a lot. * ES6, most likely friendlier for more recent versions of V8 and supported by Node.js v4+ (see [Node green](http://node.green)): * `arguments` is deprecated and is replaced by `...args` for variadic functions * most `function` keywords could be replaced by arrow functions (lexical scoping and/or concise syntax). I tend to keep `function` for top-level functions, and use fat arrows everywhere even when `this` binding isn't needed (ie. callback w/o `this`) * `array.splice(0)` could be replaced by `const copy = [...original]` * `func.apply(null, arguments)` could be replaced by `func(...args)` when first argument `this` value is indeed meant to be `null` * `package.json`: `./node_modules/.bin` is added to the `$PATH` by `npm` or `yarn`, so we could just use `"test": "mocha test/unit test/integration -t 5000"`. Yay npm! I can fork and push 4 distinct commits for this if you want, so this can be cherry-picked. A more major update would be to author in ES6/7/8 and add a transpilation step, so all runtime could use code that they can optimize best. Using babel with [babel-preset-env](https://www.npmjs.com/package/babel-preset-env) combined with [postinstall-build](https://www.npmjs.com/package/postinstall-build) is an option. This will ensure that latest versions of Node.js use mostly non-transpiled code, while older versions automatically transpile what is strictly needed. That would make things more performant for latest versions of Node.js, since V8 optimizes a lot for new syntax, while still making the GLV compatible for older versions of Node.js. The nice thing is that the build step is automatically handled at install time by npm, so no extra maven coding should be required. I think such approach could be added in future releases and is out of scope today. Also, I'm ok to transfer/donate the "gremlin" package name to Apache TinkerPop so this can be published under this name. ---
[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/695 Quick update - I plan to check this PR this weekend. ---
[GitHub] tinkerpop issue #450: TINKERPOP-1489 Javascript GLV
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/450 @jorgebay I'd be happy to help with the work on this. I recently [added partial JavaScript-GLV support to gremlin-javascript](https://github.com/jbmusso/gremlin-javascript/tree/3bdb154f41c08d5adfc65e83250eee6d57a5cab5#experimental-javascript-gremlin-language-variant). The library generates Groovy strings using [zer](https://github.com/jbmusso/zer) which is now stable/tested enough that I decided to add it as a dependency to the client. I'll soon tinker with gremlin bytecode support in zer and I think support for lambdas is easy with `Function.prototype.toString()` (ref: [mdn](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/toString)). We could maybe add Babel dependency with nashorn/ES5 presets, then parse/transpile lambdas at runtime so people can use ES2015/2016+ lambdas in their Node.js/browsers environments (though transpilation performance could be an issue, but client-side caching/memoization could certainly help). --- 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 #450: TINKERPOP-1489 Javascript GLV
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/450 Ah, it looks like [nashorn supports let and const keywords on 8u40](http://fr.slideshare.net/akihironishikawa/nashorn-in-the-future-en) so we could swap `var` for `let` and `const` unless we want to target earlier versions of Java8. I don't think adding a transpiler such as Babeljs to the mix is worth the trouble here since it's going to be a nightmare to maintain the build pipeline. However, it *could* make sense for more recent versions of Node. Node 7 would be happier with ES2015 code rather than ES5 ;) - see http://node.green/. I don't think it's realistic so I'm just putting it here for further reference, basically when Java9 is out (where [nashorn could fully support ES2015/6](http://fr.slideshare.net/akihironishikawa/nashorn-in-the-future-en)). Note that there is [a proposal for adding async iterator to JavaScript](https://github.com/tc39/proposal-async-iteration). It's currently in stage 3 so this could make it to the EcmaScript specification. Using `.next()` for async iteration might become a reality. --- 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 #450: TINKERPOP-1489 Javascript GLV
Github user jbmusso commented on the issue:
https://github.com/apache/tinkerpop/pull/450
I was thinking that supporting JavaScript `Promise` could be helpful now
that theyâve been part of the ES2015 and rolled out on most JS environment
(browsers/Node.js). Maybe this can be polyfilled under Nashorn? Using `Promise`
could complement Node.js style async functions with a callback passed as last
parameter (functions with such signature can be easily converted to functions
returning a Promise [with many third-party Promise libraries such as
Bluebird](http://bluebirdjs.com/docs/api/promise.promisify.html)). This way, a
`Traversal` could be ended with something like `.toPromise()`. I think the
following makes a lot of sense in JavaScript since itâs part of the standard:
```javascript
// JavaScript
g.V().out('created').toPromise()
.then(function (vertices) {
// do something with results
})
.catch(function (err) {
// handle error
})
.finally(function () {
// cleanup
});
// Alternatively, the end user could use use a promisifying function over
.toList():
g.V().out('created').toListAsync()
.then()
.catch();
```
Coming soon to the standard are `async` functions which return a `Promise`,
so you could do this:
```javascript
// JavaScript
async function followers() {
try {
const followers = await g.V().in('followers').toPromise();
} catch(e) {
// Handle error
}
}
```
There also are `Observable` (think: `Promise` with multiple return values,
or `Array` but laid out over time rather than in memory) that are worth
considering in JavaScript. Observable are candidate for being part of the
standard. Libraries such as RxJS v5, which aims to be spec. compliant, works
wonderfully. That way, we could also have `.toObservable()` in JavaScript:
```javascript
// JavaScript
g.V().out('created').toObservable()
.subscribe(
function (vertex) {
// This gets called once for each vertex
},
function (err) {
// Handle errors
},
function () {
// Called when observable ends (ie. after last vertex is emitted)
}
)
```
I took a different path in Node.js and started developing
[zer](https://github.com/jbmusso/zer) (short for seriali**zer**), a generic
"JavaScript-to-anything" library that uses the ES2015 Proxy object. The lib
builds an AST-ish (I'm learning these :P) which can output to anything,
including Gremlin-Groovy (currently) and most likely Gremlin-bytcode easily (it
could also output to SQL or Cypher, but hey). The trick is to `Proxy()`ify a
`Function` (rather than an `Object`) and intercept calls to that function with
`Proxy.apply()` and mutation of that function properties with `Proxy.get()`
(you can do both since functions are objects in JavaScript).
The `zer` lib allows generating queries such as
`g.V().out().in().bla().method().not().in().tinkerpop().source().code()`
(Grooovy output) but it could easily support things like
`select().from().where()` (and produce SQL-output). Coding the gremlin-bytecode
output should be trivial. It also supports nested traversals and automatic
escaping of bound parameters (it basically escapes all primitives and anything
that is not a `Traversal`). I think it could also support serializing
functions/lambdas since you can do `Function.toString()` in JavaScript and
extract the function body at runtime.
I donât think that the Proxy approach can work in Nashorn since Proxy
canât be emulated in ES5 environment (it only works in Node v6 I recall,
maybe Node v5). However, in Node.js, I think I would just use Proxy objects
that can intercept anything - I think generating code might not be worth it
there. I think this PR is valid in Nashorn but I'm unsure about Node.js.
Note that `zer` and `gremlin-javascript` are distinct libraries. Once
stable enough, `zer` (with just Gremlin-Groovy and Gremlin-Bytecode output)
could be added as a dependency to `gremlin-javascript`.
---
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.
---
