Adds JSG_NAMED_INTERCEPT

[jasnell]

This mechanism uses v8's underlying named property handler mechanism to allow a JSG_RESOURCE_TYPE to expose dynamic named properties (much like a Proxy). Currently this only supports read-only properties. The intent of this is to support the dynamic interface of a JS RPC proxy.

This is a first pass at the JSG api for this. I'm sure there is lots of room for improvement but I wanted to get something out that would allow the folks on the JS RPC stuff to make progress.

[MellowYarker]

I think registerNamedIntercept needs to be added to jsg/rtti.h's MemberCount and MembersBuilder. When I take the exact ProxyImpl defined in jsg-test.c++ (excluding testing stuff) and try to create a new class outside of jsg-test.c++ the build complains about registerNamedIntercept not being found.

[dom96]

This is really cool! Left some questions/suggestions, but good to go in general.

[MellowYarker]

Thanks for this James, very much appreciated!

[MellowYarker]

I was working on #1311 (comment) and noticed that if I JSG_FAIL_REQUIRE() from getNamed, then even if I wrap my JS in a try...catch I still get an uncaught exception.

Ex.

try {
    obj.alarm(); // This is not allowed, we should throw via JSG_FAIL_REQUIRE().
} catch(e) {
    // We don't enter here, we just terminate outright.
}

Should be able to catch a JSG exception thrown during name interception, right? Any ideas what might be wrong?

[jasnell]

Should be able to catch a JSG exception thrown during name interception, right? Any ideas what might be wrong?

Yeah, I've updated with a fix for that. Please give it a try again :-)

[MellowYarker]

Should be able to catch a JSG exception thrown during name interception, right? Any ideas what might be wrong?

Yeah, I've updated with a fix for that. Please give it a try again :-)

Works now, thanks!

[jasnell]

Ok, I'll get an internal CI run going now and if that looks good I'll get this merged. I'll likely hold off actually pulling this into the internal repo immediately tho.

[kentonv]

@jasnell Could we allow getNamed() to return an arbitrary type, which then gets JSG-wrapped?

(Most implementations would return jsg::Optional<Something> so that they can return none for properties that don't exist...)

[kentonv]

@jasnell It surprises me that this is based on inheritance, and the use of multiple inheritance makes me nervous since if you don't declare jsg::Object as the first superclass, stuff will break.

Is this NamedIntercept base class actually necessary? It looks like the implementation is templated such that the calls are always made on the derived class anyway...

[MellowYarker]

I actually ran into this problem the other day, declared the jsg::Object (in my case, Fetcher) after NamedIntercept and got segfaults for a while.

[jasnell]

Is this NamedIntercept base class actually necessary?

Probably not. I put this together fairly quickly so that @MellowYarker could make progress, fully expecting that it could be refined. I think we ought to be able to drop the base class and I want to see if I can make the three methods that need to be implemented here a bit more ergonomic.

[MellowYarker]

Just noticed that if I define a private method on my DO and try to call it from the client side, I get jsg.SyntaxError: Private field '#getPrivate' must be declared in an enclosing class and getNamed() isn't invoked.

Is there any way we can have private names also be intercepted? We want to reject calls to private methods over RPC, but I think it would be better if the script got a clear exception stating we don't allow calling private methods over RPC rather than the message above.