Reasonable, but only to an extent. :)
I think JVM languages should integrate more naturally with Java
libraries, without needing specialized wrappers. This is especially true
for a language like JavaScript, which has almost no standard library of
its own, and is thus very dependent on Java libraries.
Part of the reason for choosing to develop with a dynamic language on
the JVM (JRuby, Jython, Scala, etc.) is the ability to access the huge
extant JVM ecosystem, and of course you don't expect developers of those
3rd party libraries to specifically target one specific dynamic language
engine, especially when some of these language engines do not yet exist.
Other JVM language engines seem to do a better job than Nashorn at this,
at least currently. I'll continue to argue my case on specific issues,
but it's clear to me now that the Nashorn team has a different set of
convictions/priorities.
The alternative for me, right now, is some weird Nashorn-specific hacks.
Here's an example I just committed to the MongoDB driver:
var status = application.globals.get(String('mongoDb.status.' +
client.hashCode())) // workaround to avoid ConsString in Nashorn
A JavaScript programmer would be confused. And, this is unnecessary with
Rhino.
On 10/14/2013 01:13 AM, Rick Bullotta wrote:
I do think it is a reasonable requirement when using any arbitrary library that in some cases a
wrapper would be required. Having a method signature with "Object" is not exactly ideal
for even weakly typed interaction...kinda like an XML schema with "xsd:any". I think the
key is to avoid having to make the script developer do goofy stuff. If it requires a developer to
wrap some 3rd party library to provide necessary typing or type munging in some edge cases, that
certainly seems reasonable, doesn't it?
