Subclassing Function for interop

[resnickj]

I am working on a project that integrates with Jint but has its own interop infrastructure (the code was originally written to integrate with a different JS engine and later modified to work with Jint). The interop code relies on subclassing Jint's Function class. With an earlier version of Jint this was not an issue, but in trying to update the code to work with Jint 3.x, I've run into the following problem: the constructor protected Function(Engine engine, Realm realm, JsString? name) requires realm, which was previously available via engine.Realm, but in Jint 3.x engine.Realm has been made internal.

It seems that Function is not really intended to be subclassed by consumers of Jint now, but if not, what approaches are possible for custom interop? I see that there is a ClrFunction class, but it is designed to work with a delegate and is sealed to prevent subclassing. In an ideal world this might be sufficient, but here I am working with an existing class hierarchy based on Function, and converting to a delegate-based solution would require a significant amount of rework.

It would be nice to have the option of subclassing Function - or something like it - to provide more flexibility for interop design.

[lahma]

Can you show a minimal repro of the approach you are using to gain the features you need? I'd like to see the "bigger picture" how you utilize the inheritance and why.

[lahma]

And to add to this, APIs can always be opened when needed, we just have protective way of developing to minimize the supported API surface, adding a protected constructor is a no-brainer if the default Realm works, there just hasn't been any need so far and the user base should be quite large...

[resnickj]

Thanks for your response. I can very much appreciate the desire to minimize the supported API surface area. I'll have to spend some time looking more closely at why we are using inheritance and what exactly we gain from it. May take some days or weeks to get back to you.