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

Added a section to clarify usage inside standard collections Map/Set/WeakMap #22

Merged
merged 4 commits into from Jun 11, 2019

Conversation

Projects
None yet
4 participants
@rickbutton
Copy link
Collaborator

commented Jun 11, 2019

I've added a small section that attempts to describe the interaction with Map, Set, and WeakMap, as well as an example of each.

@rickbutton rickbutton changed the title Added a section to clarify usage inside standard collections Map/Set/ Added a section to clarify usage inside standard collections Map/Set/WeakMap Jun 11, 2019

@rickbutton rickbutton requested a review from rricard Jun 11, 2019

README.md Outdated
It is possible to use a const object or const array as a key in a `Map`, and as a value in a `Set`. When using a const object or const array in this way, key/value equality behaves as expected.
It is not possible to use a const object or const array as a key in a `WeakMap`, because const objects and const arrays are not `Objects`, and have no lifetime. Attempting to set a value in a WeakMap using a const object

This comment has been minimized.

Copy link
@ljharb

ljharb Jun 11, 2019

Why would they have no lifetime? If i make a massive const object, and then it becomes collectible, why would we prohibit engines from doing so?

This comment has been minimized.

Copy link
@ljharb

ljharb Jun 11, 2019

More to the point, an object is any value for which Object(x) === x, so these are definitely objects.

This comment has been minimized.

Copy link
@rricard

rricard Jun 11, 2019

Owner

It is collectible by the engine but like a string: the lifetime of the const object will not be observable.

This comment has been minimized.

Copy link
@ljharb

ljharb Jun 11, 2019

why deviate from language precedent? it's an object.

@rricard
Copy link
Owner

left a comment

Looks good to me. I'd like to check with @pipobscure if that's what he had in mind as well.

It is possible to use a const object or const array as a key in a `Map`, and as a value in a `Set`. When using a const object or const array in this way, key/value equality behaves as expected.
It is not possible to use a const object or const array as a key in a `WeakMap`, because const objects and const arrays are not `Objects`, and their lifetime is not observable. Attempting to set a value in a WeakMap using a const object

This comment has been minimized.

Copy link
@ljharb

ljharb Jun 11, 2019

this is something i'll bring up in committee when the time arises; these are certainly objects if Object(x) === x, and typeof x is 'object' or 'function'.

This comment has been minimized.

Copy link
@rricard

rricard Jun 11, 2019

Owner

Object(x) !== x, because Object(x) returns a mutable object.

typeof x will be constobject or record or whatever thing we need to decide on (i think that @rickbutton is working on an another PR to clarify that)

This comment has been minimized.

Copy link
@rricard

rricard Jun 11, 2019

Owner

And I did not check but #23 is that PR!

This comment has been minimized.

Copy link
@ljharb

ljharb Jun 11, 2019

no, it does not return a mutable object - Object(Object.freeze(x)) for Object x returns a frozen object. Object just returns the same thing if it’s an object, and a new mutable object if it’s a primitive.

In other words, if const objects are defined as primitives, then Object(x) must copy everything into a new mutable object.

This comment has been minimized.

Copy link
@rickbutton

rickbutton Jun 11, 2019

Author Collaborator

exactly, Object(x) will copy everything into a new mutable/regular/typeof z === "object" object.

This comment has been minimized.

Copy link
@ljharb

ljharb Jun 11, 2019

in that case, it sounds like this proposal defines new primitives, so “const object” would be a misleading name (i see the proposal is named const value types, so i must have gotten confused seeing that verbiage somewhere)

This comment has been minimized.

Copy link
@rricard

rricard Jun 11, 2019

Owner

We do not have the same semantics as Object.freeze here. Yes we'd copy everything to the new mutable object

This comment has been minimized.

Copy link
@rricard

rricard Jun 11, 2019

Owner

in that case, it sounds like this proposal defines new primitives, so “const object” would be a misleading name (i see the proposal is named const value types, so i must have gotten confused seeing that verbiage somewhere)

Yes we're kind of trying to find a new name instead of const value types. I think I'll open an issue soon about it

@pipobscure

This comment has been minimized.

Copy link
Collaborator

commented Jun 11, 2019

LGTM

@rricard rricard merged commit 0f233fc into master Jun 11, 2019

@rricard rricard deleted the rb/clarify-usage-in-collections branch Jun 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.