Compat regression fix: Hash#to_n
should return a JS object
#2613
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before we have merged a Hash->Map patchset,
Hash#to_n
used to return a JS object, then it returned Map.#to_n
is an API of thenative
library, so it is called by the unwrapping part. Let's suppose a sample JS library, that is often called like this inside JS:This sample is very similar to how Ruby kwargs work, or at least used to, or still work this way in Opal. Such a code was represented in Opal this way:
Or... without kwargs, the second line becomes:
After the Hash->Map patchset, this code has changed its behavior, now passing hash as a Map, which is breaking compatibility assumptions. From what I know, Map is very rarely used in JS and the JS libraries can be assumed to never expect a Map, but a JS Object.
This commit restores previous behavior of
Hash#to_n
returning a JS object, like before.Thanks to Jean-Eric Godard (@jeezs) for reporting this bug.