JSRT APIs for Proxy

[kunalspathak]

Currently target and handler as internal fields of JavascriptProxy.cpp and there is no way to retrieve them natively. Recently node started taking dependency on these fields natively. This breaks node on chakracore as chakracore doesn't have these fields exposed via JSRT. Additionally as per ES6 spec, there is no way to check if an object is a proxy or not.

This issue is to track adding below JSRT APIs

• GetTargetOfProxy
• GetHandlerOfProxy
• IsProxy

[dilijev]

@digitalinfinity is this still needed?

[digitalinfinity]

Yes, the v8 Proxy implementation in chakrashim is still just a stub

[rhuanjl]

Do you want a PR for these? Looks easy enough.

My only questions would be:
a) whether they should really be 3 separate APIs?
b) what sort of test should be there for this functionality - particularly if it's 3 separate functions adding them as callable methods in ch may start bloating ch's API a bit

[rhuanjl]

Maybe something like this:

JsGetProxyProperties(_In_ JsValueRef proxyObject, 
           _Out_ bool* isProxy,
           _Out_opt_ JsValueRef* Target, 
           _Out_opt_ JsValueRef* Handler);

[dilijev]

Do you want a PR for these?

Sure! Let's hash out what's needed first and how we will test it. I'd imagine a NativeTests addition for this would be part of it.

[rhuanjl]

Options for the API:

1. One function:

JsGetProxyProperties(_In_ JsValueRef proxyObject, 
           _Out_ bool* isProxy,
           _Out_opt_ JsValueRef* Target, 
           _Out_opt_ JsValueRef* Handler);

Call it with a normal Proxy would output:
isProxy = true
And values for Target and Handler.

Call it with a revoked Proxy, would output:
isProxy = true
BUT nullptrs for Target and Handler

Call it with something that is not a proxy and you'd be given:
isProxy = false
And nullptrs for Target and Handler

2. two functions:
   One for IsProxy - the other to get target and Handler.

3. All 3 functions separately.

Options for testing:

1. If done as one function could track it into ch and fire several tests at it from JS
2. If done as multiple APIs should probably have a native test rather than implementing multiple new APIs in ch for one thing

Thoughts?

[dilijev]

I like the elegance of one function. Let's explore that first. I think it's probably fairly likely if they want to know Target they will also want to know Handler, and need to guard accessing those on whether the object is a proxy at all.

There's value in keeping the APIs lean and this will be an experimental API at first so we could provide fewer APIs at first and go from there if there are perf concerns. If getting all the information has significantly more overhead and "all the info" is not the most common scenario in practice, then we can explore splitting up the API.

I can imagine this pattern being pretty common:

JsGetProxyProperties(obj, &isProxy, &target, &handler);
if (isProxy) { doSomethingWith(&target, &handler); }

@digitalinfinity what do you think? Also would you like this change targeted at master or release/1.9?

[jackhorton]

@rhuanjl Any updates on this? If you don't plan on writing this, thats fine, but Node's new util.types.isProxy() requires this functionality.

[jackhorton]

And, for that reason, I vote that any such change go into release/1.9 unless we plan on making 1.10 very soon.

[rhuanjl]

@jackhorton I was waiting on further comment before writing anything as the ask didn't seem quite fixed yet.

I'll have time to write the code this weekend if we can be sure what's wanted before then.

[jackhorton]

I agree with @dilijev about the design strategy. I don't think there will be a perf impact to get the target and handler, but also we could perhaps pass null for those if we don't want that information and are concerned about doing extra work.

[jdalton]

Just a heads up chakra-node has shipped v10 so now beyond util.inspect() with showProxy not working there is also util.types.isProxy() which doesn't work either.