Change jsObject.value
to return the underlying: Map
#676
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.
After #674,
jsObject.value
would never be used internally (which is great for heap usage and to avoid rehashing), but it's still vulnerable to #186. This PR changesjsObject.value
to return theunderlying
Map directly.The scaladoc says "The value of this JsObject as an immutable map", but the type signature is only
scala.collection.Map
. Anyone requiring ascala.collection.immutable.Map
would need to call.toMap
anyway or do an.asInstanceOf[s.c.i.Map]
.If we just return
m
directly and change remove "immutable" from the scaladoc, it would do good things for memory footprint and throughput.Before:
TreeMap (#675):
This PR:
One minor caveat: this would shift the responsibility for handling hashCode collisions onto users, but this method isn't suggested usage and we didn't handle them previously anyway.
This is an alternative to #675, although there's active discussion happening in #675 (comment).
@gmethvin