-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Function Call should support recv argument #159
Conversation
Codecov Report
@@ Coverage Diff @@
## master #159 +/- ##
==========================================
- Coverage 97.50% 97.46% -0.05%
==========================================
Files 12 12
Lines 481 473 -8
==========================================
- Hits 469 461 -8
Misses 8 8
Partials 4 4
Continue to review full report at Codecov.
|
As I mentioned in #156 (comment), I think that would be a useful convenience method even with the breaking change. It would also reduce the need for using Function.Call directly. Making the receiver explicit in Function.Call is independently useful in making Function.Call more generally useful when passing an explicit receiver is necessary, to avoiding the confusion that comes from implicitly passing |
Ok I will leave this PR here and we can merge it if passes review and we plan to ship a release of v8go with the breaking change. I can make a separate PR for the new object.methodcall suggested. |
5d09ce1
to
dc93602
Compare
441eae1
to
1e0335d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small comment; otherwise looks good.
I'm ok with the breaking change as we are on 0.x and we have already made some breaking changes with using panic rather than returning null errors.
Would be good to document some of these breaking changes in the Readme.
(cherry picked from commit 991ab09)
E.g. so undefined can be passed in
4f38145
to
aeeeab1
Compare
They are being documented in the CHANGELOG.md and when a release is made, we could copy that text to the release description. Those seem like the places where someone would go to find information on changes relevant to an upgrade. Probably the main point of confusion with the README is that someone encountering the project for the first time will see the README for the |
Alternatively, perhaps it would be a good time to make a new release, which would also avoid the confusion from unreleased breaking changes. |
I think this is a good idea; a new release is overdue. |
(cherry picked from commit 991ab09)
Fixes #156
The v8go library is implicitly passing
undefined
as the receiver when executing a functionCall
. To make this configurable, as shown in this PR, it would be a breaking change to the v8go api for the function object. This change ensures the explicit passing of a receiver to a function and avoid additional confusion around the fact that functions obtained from an object are not bound to the object they are obtained from. If we want to avoid the breaking change, we could instead expose something on the v8go object type calledMethodCall
which would ensure the proper execution a function/method with the object as it's receiver and avoid code like:And instead may look like:
The choice is essentially - a breaking change that aligns the function call with the v8 api or deviating a little from the v8 api by exposing a new method on objects.