I *don't think* there should be any (un)wrapping applied to JSObject
method calls. The api doc says: "Nashorn will treat objects of such
classes just like nashorn script objects."
And, personally, I'm fine with that. That will allow me to provide more
efficient implementation of java objects in
I need to check that out. But, is there any specific reason why it
should be different? User implemented JSObject receives Object (for set,
call) and returns Object. If script object is passed as argument to
those, do you think that should be wrapped as mirror? if so, why?
-Sundar
On Friday 1
I mean methods of JSObject such as (get/set)(Member/Slot) and call(). I
hope object passed to/from those will not be wrapped/unwrapped, although
the are technically Java methods .
SM
On 10/16/2014 9:01 PM, A. Sundararajan wrote:
There is no notion of wrap/unwrap of user implemented JSObject
There is no notion of wrap/unwrap of user implemented JSObject - so
those won't be affected. JSObject itself is just another Java type and
so would be between script and Java code "as is".
Only for Object param types of Java methods will receive wrapped
ScriptObjects - argument filter will be
Sundar
Will it also affect classes implementing JSObject?
IMO, we should have an option to disable this wrap/unwrap behavior in
cases when it significantly affecting performance.
SM
On 10/16/2014 6:44 AM, A. Sundararajan wrote:
There were many questions in this list and elsewhere on
ScriptOb
There were many questions in this list and elsewhere on
ScriptObjectMirror. This email is to clarify those.
Nashorn represents JavaScript objects as instances of implementation
class called jdk.nashorn.internal.runtime.ScriptObject or one of it's
subclasses (like NativeArray, NativeRegExp etc.
