There are concepts which are very similar, yet different and confuses many people.
Referential transparency vs immutability
Referential transpa...
For further actions, you may consider blocking this person and/or reporting abuse
this is a
TypeError
because by assigninga
a new object value you are changing the prototype as well. Note:a = { x: 3 }
wouldn't work either because while this new object's prototype has the same signature as the original value ofa
it is still a new prototype.I would say referential transparency is in different realm, this is not a type error in common case (though can seem like one in some cases).
It is in different realm the same way as borrow checker in Rust. Immutability is also in different realm, but can be modeled with types, for example with
Readonly<T>
in TypeScript or$ReadOnly<T>
in Flow.I might be wrong, but
is actually assigning a pointer to an object to
a
, so this:cannot work, because you are changing the value of
a
with a new pointer.no problem with
because you don't change the value of
a
: it's still the same pointer to the same object.So to me it's correct to say
const
for immutability, because in your example it's not possible to change the real value ofa
(which is an address).As I said, I might be wrong, but it's how I understand the concept and for now it hasn't failed me yet 😄
Referential transparency - means you can't reassign variable.
Immutability - means you can't mutate object.
The
__proto__
and theprototype
... Enough said.I always get the authentication and authorization terms wrong even when I know there is a difference between them.
Great article! Didn't know about
Object.freeze