Skip to content
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

Allow overriding the received (this) of a jsg::Function, update forEach impls #1027

Merged
merged 4 commits into from
Aug 18, 2023

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Aug 17, 2023

The jsg::Function will automatically set the receiver when mapping
from a JS function to jsg::Function. This is not always what we want.
In many cases we have to be able to override the receiver on a case
by case basis. This pr introduces the ability to change the receiver
on a jsg::Function, and updates the various forEach method impls to
use jsg::Function instead of directly using v8::Function calls.

@ohodson
Copy link
Contributor

ohodson commented Aug 17, 2023

lgtm modulo my naive question about value vs object for the receiver. Probably good to have a second opinion though.

The jsg::Function will automatically set the receiver when mapping
from a JS function to jsg::Function. This is not always what we want.
In many cases we have to be able to override the receiver on a case
by case basis.
@jasnell jasnell force-pushed the jsnell/jsg-function-override-receiver branch from b6131ee to 7d8521c Compare August 18, 2023 16:50
jsg::Optional<jsg::Value> thisArg);
void forEach(jsg::Lock&,
jsg::Function<void(kj::StringPtr, kj::StringPtr, jsg::Ref<URLSearchParams>)>,
jsg::Optional<jsg::Value>);
Copy link
Contributor

@Warfields Warfields Aug 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly just learned something about c++, just want to verify before I make any assumptions. Can you always just list types in the header, and then let the implementation name the variables or is this a special case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. I know there are differences of opinion on this about whether it is desirable but personally I prefer the more abbreviated form in declarations when the intent is clear.

@jasnell jasnell merged commit 724b7dd into main Aug 18, 2023
@kentonv kentonv deleted the jsnell/jsg-function-override-receiver branch August 18, 2023 18:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants