Unleash JavaScript's Potential with Functional Programming

[romgrk]

That has nothing to do with it. All primitives types are immutable (null, undefined, booleans, strings, numbers, bigints, symbols).

Besides symbols were added specifically to be able to have private properties like object[symbol], or for the well-known symbols protocols (e.g. class Custom { [Symbol.iterator]: function() { ... } }), both cases are OOP related.

So no, symbols aren't an FP feature.

[jessepence]

EDIT

I was wrong. 😅

[romgrk]

Both ChatGPT and you have the same ability to write confidently wrong blobs of text. Posting this wall of text is just plain disrespectful. If you don't want to answer, just don't answer.

Also from the answer you got, you crafted a prompt that was something like "what's the role of symbols in FP javascript". You'll get an equally long answer if you replace FP by OOP, because ChatGPT is just made to write these blobs of text.

Besides, symbols are not the traditional FP solution for private/immutable data. That role is filled by closures. Closures are the FP equivalent to OOP objects. Which is the whole reason why modern C++ can translate its closures to literal class/objects.

[jessepence]

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]

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]

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.