-1

Noticing this behavior with javascript constants... It looks like the const keyword loses immutability when dealing with objects.

Would like to know your opinions regarding this behavior?

const fruits = 'banana';
fruit = 'apple';
console.log(fruit); // 'banana'  as expected

//----------------------------------------------------------------------

const fruit = ['apple'];
fruit.push('banana');
console.log(fruit); // ['apple', 'banana'] ???????

fruit = 'anything';
console.log(fruit); // ['apple', 'banana'] as expected;

//----------------------------------------------------------------------

const brands = {};
brands = [];
console.log(brands); // {} as expected

brands.sony = "playstation"
console.log(brands); // {sony:'playstation'} ???????
Leo Javier
  • 1,383
  • 12
  • 19
  • 4
    From MDN: `The const declaration creates a read-only reference to a value. It does not mean the value it holds is immutable, just that the variable identifier cannot be reassigned.`. Does that help? – Mjh Jun 15 '16 at 13:26
  • 1
    Please read [ask] before asking a question. The first heading on that page is "Search, and research". This is already covered in many, many places on the internet. – Heretic Monkey Jun 15 '16 at 13:29
  • Where an object is assigned to a variable, the value of the variable is a reference to the object. Where the variable is created using *const*, it's the reference that is immutable, not the object. – RobG Jun 15 '16 at 13:34

2 Answers2

3

Javascript constants, as Java constants, are immutable. But you must see them as pointers to values. They will always refer to the same value. That value can be a primitive one or an object. So you cannot change the reference to another object, but you can modify that object (if it is modifiable, primitive types aren't).

const TEST={ name: 'myObject'}
TEST= ... // this always does nothing, the current reference cannot be changed
TEST.name=... //this changes the state of the current reference.

@Jess' answer offers you the way to make an object unmodifiable.

Pablo Lozano
  • 10,122
  • 2
  • 38
  • 59
1

Object.freeze and Object.seal will introduce the functionality you're looking for. Both methods will prevent new properties being added or existing ones removed, while the former will also stop existing ones being edited.

I like the current use of const, for instance when declaring large modules or namespaces at the top of files. It's just a little bit of protection from the whole lot getting overwritten, while still letting you interact.

Jess
  • 345
  • 1
  • 3
  • 17
  • 1
    *const* doesn't really help much in that regard. If something tries to overwrite it and fails, then whatever was dependent on the overwriting will now fail, even if the "first in" doesn't. In both cases, the issue should be detected in testing. – RobG Jun 15 '16 at 13:37
  • @RobG You are correct it should be caught in testing, however not everyone is blessed with a team which follows best practises with regards to testing! Also, if the error is not immediately obvious, a dev could waste a lot of time before testing discovers the error- using a `const` instead of a `var` costs nothing. – Jess Jun 22 '16 at 08:20