search

sebastienros / jint

Javascript Interpreter for .NET
BSD 2-Clause "Simplified" License
4.11k stars 563 forks source link

Fix throwing on accessing CLR FunctionDeclaration #1949

Closed lofcz closed 2 months ago

lofcz commented 2 months ago

I'm open to finding a better solution to the problem described below, as the current fix has weird ergonomics.

Accessing FunctionDeclaration of a MethodInfoFunction (CLR functions) currently throws - the test* included describes the scenario. I believe accessing the property should never throw (I hate linking to MSDN, alas: https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/property?redirectedfrom=MSDN). This forces a sprinkle of ! in the codebase in places where we know the function is not a CLR function (this is the part I don't like).

*I've included two tests now, one for the delegate, and one for the method info function.

Unrelated to this, for the debugger I'm working on, I'd need to make at least some information of MethodInfoFunction and DelegateWrapper public to provide information about the native function (get the parameters, largely the same thing Jint does internally). This is outside of this PR's scope, just announcing ahead of time to discuss, should there be objections to that.

This would be:

lofcz commented 2 months ago

The failing test is something flaky with async implementation, unrelated.

lahma commented 2 months ago

Unrelated to this, for the debugger I'm working on, I'd need to make at least some information of MethodInfoFunction and DelegateWrapper public to provide information about the native function (get the parameters, largely the same thing Jint does internally).

So I guess you need the typed params and it would not be enough to implement CLR method's custom IFunction descriptor which would return the names which IFunction has a property for. Creating such fake wrapper would also offer always non-null function declaration.

lofcz commented 2 months ago

I pondered the IFunction idea but ultimately I don't see the fake wrapper as able to expose the data I need (typed params). If you are ok with it, I can create a PR tomorrow exposing the members listed above.

Probably also XML doc for IFunction? FunctionDeclaration to explain that it's always null for CLR functions.