convert NativeMath and NativeJSON into a Lambda based ScriptableObject

[rbri]

and add the toStringTag property

[p-bakker]

Given that it unbreaks a test in test262 and that IMHO the new code is MUCH easier to reason with, I'm all for this change

Are there any other upsides (performance?) or maybe some downsides to using a Lambda-based impl. vs. the IdScriptableObject approach?

[rbri]

For me the impl of the toStringTag property based on lambda was simpler and it was just a test to see how hard it might be to do the same for RegEx. This is the next on my list (but after the vacation in october).

Regarding positive/negative side effects i guess @gbrail knows more.

But overall for me having this lambdas opens up some great improvements, its much simpler and more straight forward to implement the stuff in this way.

[p-bakker]

But overall for me having this lambdas opens up some great improvements, its much simpler and more straight forward to implement the stuff in this way.

Yeah, it looks sooo much cleaner :-)

[p-bakker]

Any idea yet whether the Lambda approach will make #963 / #1181 (comment) easier?

[gbrail]

Yes, I'm happy to see this too. I actually don't think that there are big downsides to the lambda approach -- I also found native JS stuff to be easier to implement that way as it maps much more directly to the native way that JavaScript works, and furthermore I've tested the performance and I don't recall seeing a significant difference.

One side note on all this -- it'd be easier for me if we start marking PRs "draft" if you are doing it just for discussion, or want input, and un-marking them "draft" when you want them to be seriously considered for merging.

For this particular case, I'm happy to merge this unless there are other concerns.

[rbri]

i like to see it merged because it fixes two more test

[gbrail]

I think this works and makes sense. Thanks!