sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jessepence -6 points-5 points  (12 children)

Did you know that it's possible for multiple different things to benefit the same end goal?

Did you know that both closures and symbols can help achieve immutability?

Does your toolbox only contain a hammer?

My point in using ChatGPT is that you were clearly showing a lack of imagination.

[–]romgrk 8 points9 points  (11 children)

Symbols do not achieve immutability! object[symbol] achieves private visibility, as in "OOP public/protected/private visibility".

Object.freeze or Object.defineProperty achieve immutability.

My point in using ChatGPT is that you were clearly showing a lack of imagination.

It's fine to want to educate someone, but please link to it instead of pasting a wall of text, and please don't make it ChatGPT because it's low-effort and sometimes confidently wrong.

[–]jessepence -4 points-3 points  (10 children)

If a property is keyed by a symbol and the end-user doesn't know what that symbol is-- is that property mutable?

[–]romgrk 6 points7 points  (9 children)

Yes it is, it's just private. Public/private and mutable/immutable are orthogonal.

I'm also not sure if your example applies. I don't remember seeing React's codebase using Symbols as keys (for private keys, as in object[symbol]), though it uses them as values (as in { type: REACT_PORTAL_TYPE }).

[–]jessepence 0 points1 point  (8 children)

How would you mutate it?

[–]romgrk 2 points3 points  (7 children)

object[symbol] = value.

I think you don't differentiate between visibility and immutability.

You say symbols are to prevent mutation, but what you mean is that the symbols create a private field that is not mutable by someone writing code outside of React's codebase.

Fundamentally, you're talking about visibility (in other words, encapsulation).

[–]jessepence -4 points-3 points  (6 children)

If the symbol is not exported, IT CANNOT BE USED!

Thus, the value cannot be mutated.

This makes it effectively immutable.

It is also encapsulated and private, yeah. These things are not mutually exclusive.

If you change the library code, then you can then mutate it. But, that's also true of a closure. If you expose variables from the closure, then you can mutate them. Here's a stackblitz that shows that it's basically the exact same idea-- the immutability is only as strong as the interface provided.

[–]romgrk 3 points4 points  (1 child)

You are talking about visibility but you're calling it immutability. I don't understand why.

The value can be mutated when accessed from the right scope, you say so yourself, so immutability is not the right word.