A tiny response to ThePrimeagen

DiadeTedio Tedio
3 min readMay 3, 2024

--

Okay. I’ll argue here, you don’t need to unban me, I just want to tell which was my point and why I think I was justified in saying what I said. So, just listen a bit.
I’m a C# guy, so my terminology was a bit biased towards terms we use there, but the notion of “reference types” is common and it is used in many languages. What I was saying about references is what I was saying about reference types. Reference types are opposed to what we call ‘value types’.
In most low-level languages this kind of distinction does not make much sense because all values are stored inline and modified inline if you don’t specify it explicitly, but it does make sense in languages like C#, Kotlin (well, probably any JVM language), JS and Swift where you have a distinction of how you refer and handle these types. Reference types are types that you “never” deal with directly but through references (generally, obviously I’m giving a simplified response here so I’ll cut corner cases and specificities). So with reference types you are every single time dealing with a reference, when you change the values of that reference you are changing the values somewhere else. Value types in the other hand are types that are treated like values (literally), you handle and deal with them as if their identity were determined by their content (generally), so when you change it you will usually be changing it directly and inline (if the language allowed it, C# for example does with structs but Java don’t as it only have primitives as value types currently, whatever). The distinction between reference types and value types is a bit complex and confuse because some languages have a bunch of special corner cases here and there (like C# for example, which would call a string a reference type even it is used as a value type and when it is immutable, because it is shared by reference and whatever). Reference types can be thought as almost literally pointers in low-level languages (althought how languages and runtimes will deal with them internally is a completely different question), so when you have something like:
```
var x = “this is a string”;
var y = x;
```
in C#, you are assigning the string pointer to ‘x’ and when you assing y to x you are assigning only the pointer of ‘x’ into ‘y’, not it’s value.

Given that distinction, given that knowledge, I said const did make sense in JS, I said this because JS has “kind of” a concept of reference types and value types, and this concept does make const make some “minor sense” (I don’t know if this is the right expression but whatever). Value types in JS are the primitives, they are dealed with and treated like values and their identity is expressed in terms of their content, so when you const them you will never be able to change them. Reference types in JS are the “objects” and their identity is given both by their content (in the sense of usage) and by their real referential identity (in the sense of how the language deals with them, you can assert this my making something like { a: true } == { a: true }, it will give you ‘false’ because their referential identities are not the same, because they are two different objects, where if you type 1000 == 1000 the response will be true because numbers are value types and their identity is their value, the same is generally true with strings in JS).

Given this, when I said it does make sense I did it because when you do:
```
const x = { a: true };
```
You are turning to constant not the inner refered object but rather the reference itself (which is the identity of that object), in other words it means you are saying “this variable here can only accept this reference here as it’s value”, this is why it makes a “minor sense”, because references themselves are identified as unique things in JS, implied.

I’m not saying this is good, I think it causes confusion (because even if the reference is constant, the inner value is not).
I’m not saying I want this (I don’t).
I’m just saying things work this way, not only internally but also for the developer who is dealing with this.

Well, anyway, this is my “full summarized point” and you can agree or not and sorry for any typos, but I’d rather argue here than leaving this without a decent response.

Some references on the distinction:
Swift, C#, JVM, JS, Wiki

--

--