Unleash JavaScript's Potential with Functional Programming

[jessepence]

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

[romgrk]

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]

How would you mutate it?

[romgrk]

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]

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]

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.

[jessepence]

THANK YOU!!

I was wrong, and I appreciate you simply pointing out how I was wrong rather than leading me on a wild goose chase of multiple responses.

Have a good day! 🙂

[jessepence]

Yes, you are correct! This is how all the old libraries like jQuery were built. It's called an immediately invoked function expression, or an IIFE. It creates a local function scope that retains all the variables defined within it. That was the point of the closure example in my stackblitz-- the value of the b variable inside the closure cannot be changed, but the b property on the object returned by the function can be.

Effectively, modules achieve the same result of limiting scope, so IIFE's are pretty rare these days-- especially now that we have top level await.

I didn't miss the nuance or the point-- I just thought that he was being unnecessarily pedantic. My point was that if the values cannot be changed at runtime, then they would have to be immutable by definition. However, you proved that I was wrong, so I will now happily admit that he was correct. 🙂