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

Cache wrapped object returned by WrapObjectHandler #1327

Merged
merged 1 commit into from Oct 23, 2022

Conversation

Genteure
Copy link
Contributor

As discussed with @libaowei on Gitter related to #1321 and #1326, turns out they has some script that rely on some non-standard behavior of a older version of Jint. Because they want to maintain compatibility for those scripts they decided to use a custom object wrapper.

This pull request make the object wrapper cache available to WrapObjectHandler through argument, which was their original intention if I understand correctly.

@lahma
Copy link
Collaborator

lahma commented Oct 23, 2022

Because there's already configuration property TrackObjectWrapperIdentity which should be respected. Would it make more sense to have another layer for retrieving the wrapper. Basically one like (pseudo):

GetWrapper {
   if cached => return cached;
   cached = TheDelegate(original params)
   return cached
}

There should be no need to expose the cache itself. So could use 90% of the original wrap handler and call the customization and store into cache.

@Genteure
Copy link
Contributor Author

Yes it does make sense. Changed as suggested.

@Genteure Genteure changed the title Expose wrapper cache to custom WrapObjectHandler Cache wrapped object returned by WrapObjectHandler Oct 23, 2022
@Genteure
Copy link
Contributor Author

Not sure why it's failing on linux, I can't reproduce on my Windows machine, I'll take a look tomorrow.

Copy link
Collaborator

@lahma lahma left a comment

Choose a reason for hiding this comment

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

Looks good, the Linux build seems to have trouble at times. Shouldn't be related to this.

@lahma lahma merged commit 660f6ad into sebastienros:main Oct 23, 2022
@lahma
Copy link
Collaborator

lahma commented Oct 23, 2022

Thank you!

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.

None yet

2 participants