7 ms·

Could you explain why? I don’t really know JS.

defen 6y ago
const prevents rebinding a name but doesn't affect the variable's mutability. const foo = {}; foo = 42; //not allowed foo.bar = 'baz'; //this is fine
- Arelius 6y ago
  Sure, this describes the problems with JS's const, but doesn't really describe why it shouldn't be used?
  - lhorie 6y ago
    Most JS people consider it perfectly fine to use it. It's a just a tool. A minority wants to make a storm in a cup of water because they read this[1] [1] https://jamie.build/const https://jamie.build/const
    - edf13 6y ago
      He’s an angry chap isn’t he?
      - lhorie 6y ago
        If you ever feel compelled to google him, you may want to grab some popcorn first :)
    - giantDinosaur 6y ago
      Hmm, some good points there. I think I'll avoid const now.
      - yashap 6y ago
        I didn’t think any of these points were very strong. const x = {immutableValue} That tells me the thing is fully immutable. Whether it’s a global variable or not, that’s still nice to know when reading the code! Likewise: let x = {immutableValue} const x = {mutableValue} These tell me different things. The first tells me I should look out for re-assignment, the second that I should look out for mutation of the value. In contrast, this: let x = {mutableValue} Clearly has the most cognitive load. Anything could happen with this. If it’s a bigger, more complex function/whatever, “what happens to x, it could be anything” is just one more thing to fit in my head as I try to figure out what this code does. Enough little uncertainties like this, and I have to give up understanding by reading entirely, and resort to a debugger. Had the author limited the scope of what was possible, it’d be a bit easier to understand, with really no drawbacks. It’s not the end of the world, but “small, simple, easy thing I can do to make the code easier to understand for future readers” ... why not do that?
        giantDinosaur 6y ago
        Really, I just have a somewhat FP bias, and I'd really enjoy it if const was actually immutable, since it'd be a nice concise way of expressing that. It's just not as useful as you'd think given how often it seems to be used (by contrast I almost never see anyone actually making anything immutable in JS).
        yashap 6y ago
        I like FP too, but most languages, including FP ones, have both mutable/immutable references and mutable/immutable values. And in JS, things like strings, numbers and booleans are immutable value, plus immutable.js is quite popular for immutable data structures, especially in React+Redux apps.
    - russellbeattie 6y ago
      Nice projection. I say over-using const is a fad (which it is) so you repeat it. I have zero idea who that guy is. Not even bothering to click, actually, as I'm sure he's just going to say what I said.
      - lhorie 6y ago
        Ironically, I think your comment falls into the same cognitive trap as the const vs let thing: the always-use-let argument is usually that const does not mean immutable data structure and that fact is confusing, so you should let to signal that the data structure is mutable, even though what let really means is to make the binding mutable, not to indicate anything about the data structure it points to. The counter-argument - despite what it may seem - is not the opposite stance, but rather that because bindings and data structures are two different things, conflating the two is confusing. Likewise, I'm saying that a minority is vocal because reading a rant from a OSS celebrity either reaffirms their preconceptions or sways them through aggressiveness (both of which are objectively true, as I have witnessed cases of both), but you're accusing me of projecting (presumably because you think that I'm making a claim about you personally - which is not true). Consider that some of the words you use are weasel words ("overusing", "fad"), which, IMHO imply a tautology (i.e. "I think X, therefore X", as opposed to "The facts are X, therefore Y"). I originally said that the spec is clear about what const and let are. Implying that following the spec is a fad is needlessly derogatory and doesn't address the double standard with regards to the confusing-ness of const vs let.
- Lio 6y ago
  Yes but why do you consider that bad? It’s the same behaviour in many other languages. Why would rebinding variables ever be a good thing?
- mmis1000 6y ago
  Isn't that literally the same as java or a const pointer in c/c++? const fixed the pointer but don't prevent user change the value in the storage it point to.
  - jpcooper 6y ago
    There are two possibilities in C++. I am not sure what the situation is in Java. It is possible to define a pointer to an object whose contents may not be changed. This is done with ‘const * type object’. If you want a pointer whose value must not change, but do not care about the contents of the pointed to object, you would write ‘type * const object’.
    - eMSF 6y ago
      You ought to have mentioned that pointers of the latter type are quite rare in C. A mention of const pointer practically always means a pointer-to-const: a pointer you can't write through. Often you can still "re-bind" such pointer to another object – in both ways the polar opposite of JS const. Of course, in C++ there are const references as well, and in this case const also means you can't modify the referenced object (in any case in C++ you can never re-bind a reference).
  - jansan 6y ago
    It's the same in Java and never caused any problems. You just have to understand what const does. What the OP is looking for is Object.seal() and Object.freeze(). This is a pointless discussion.
- dtf 6y ago
  There's a record & tuple proposal that would address this use case (currently served by tools such as Immer): const foo = #{}; foo = 42; //not allowed foo.bar = 'baz'; //not allowed https://2ality.com/2020/05/records-tuples-first-look.html https://2ality.com/2020/05/records-tuples-first-look.html
- afiori 6y ago
  const is useful when multiple part of a program might refer to the same object/value, blocking rebindings is what you need to keep all the references in sync.

const prevents rebinding a name but doesn't affect the variable's mutability. const foo = {}; foo = 42; //not allowed foo.bar = 'baz'; //this is fine

Arelius 6y ago
Sure, this describes the problems with JS's const, but doesn't really describe why it shouldn't be used?
- lhorie 6y ago
  Most JS people consider it perfectly fine to use it. It's a just a tool. A minority wants to make a storm in a cup of water because they read this[1] [1] https://jamie.build/const https://jamie.build/const
  - edf13 6y ago
    He’s an angry chap isn’t he?
    - lhorie 6y ago
      If you ever feel compelled to google him, you may want to grab some popcorn first :)
  - giantDinosaur 6y ago
    Hmm, some good points there. I think I'll avoid const now.
    - yashap 6y ago
      I didn’t think any of these points were very strong. const x = {immutableValue} That tells me the thing is fully immutable. Whether it’s a global variable or not, that’s still nice to know when reading the code! Likewise: let x = {immutableValue} const x = {mutableValue} These tell me different things. The first tells me I should look out for re-assignment, the second that I should look out for mutation of the value. In contrast, this: let x = {mutableValue} Clearly has the most cognitive load. Anything could happen with this. If it’s a bigger, more complex function/whatever, “what happens to x, it could be anything” is just one more thing to fit in my head as I try to figure out what this code does. Enough little uncertainties like this, and I have to give up understanding by reading entirely, and resort to a debugger. Had the author limited the scope of what was possible, it’d be a bit easier to understand, with really no drawbacks. It’s not the end of the world, but “small, simple, easy thing I can do to make the code easier to understand for future readers” ... why not do that?
      - giantDinosaur 6y ago
        Really, I just have a somewhat FP bias, and I'd really enjoy it if const was actually immutable, since it'd be a nice concise way of expressing that. It's just not as useful as you'd think given how often it seems to be used (by contrast I almost never see anyone actually making anything immutable in JS).
        yashap 6y ago
        I like FP too, but most languages, including FP ones, have both mutable/immutable references and mutable/immutable values. And in JS, things like strings, numbers and booleans are immutable value, plus immutable.js is quite popular for immutable data structures, especially in React+Redux apps.
  - russellbeattie 6y ago
    Nice projection. I say over-using const is a fad (which it is) so you repeat it. I have zero idea who that guy is. Not even bothering to click, actually, as I'm sure he's just going to say what I said.
    - lhorie 6y ago
      Ironically, I think your comment falls into the same cognitive trap as the const vs let thing: the always-use-let argument is usually that const does not mean immutable data structure and that fact is confusing, so you should let to signal that the data structure is mutable, even though what let really means is to make the binding mutable, not to indicate anything about the data structure it points to. The counter-argument - despite what it may seem - is not the opposite stance, but rather that because bindings and data structures are two different things, conflating the two is confusing. Likewise, I'm saying that a minority is vocal because reading a rant from a OSS celebrity either reaffirms their preconceptions or sways them through aggressiveness (both of which are objectively true, as I have witnessed cases of both), but you're accusing me of projecting (presumably because you think that I'm making a claim about you personally - which is not true). Consider that some of the words you use are weasel words ("overusing", "fad"), which, IMHO imply a tautology (i.e. "I think X, therefore X", as opposed to "The facts are X, therefore Y"). I originally said that the spec is clear about what const and let are. Implying that following the spec is a fad is needlessly derogatory and doesn't address the double standard with regards to the confusing-ness of const vs let.
Lio 6y ago
Yes but why do you consider that bad? It’s the same behaviour in many other languages. Why would rebinding variables ever be a good thing?
mmis1000 6y ago
Isn't that literally the same as java or a const pointer in c/c++? const fixed the pointer but don't prevent user change the value in the storage it point to.
- jpcooper 6y ago
  There are two possibilities in C++. I am not sure what the situation is in Java. It is possible to define a pointer to an object whose contents may not be changed. This is done with ‘const * type object’. If you want a pointer whose value must not change, but do not care about the contents of the pointed to object, you would write ‘type * const object’.
  - eMSF 6y ago
    You ought to have mentioned that pointers of the latter type are quite rare in C. A mention of const pointer practically always means a pointer-to-const: a pointer you can't write through. Often you can still "re-bind" such pointer to another object – in both ways the polar opposite of JS const. Of course, in C++ there are const references as well, and in this case const also means you can't modify the referenced object (in any case in C++ you can never re-bind a reference).
- jansan 6y ago
  It's the same in Java and never caused any problems. You just have to understand what const does. What the OP is looking for is Object.seal() and Object.freeze(). This is a pointless discussion.
dtf 6y ago
There's a record & tuple proposal that would address this use case (currently served by tools such as Immer): const foo = #{}; foo = 42; //not allowed foo.bar = 'baz'; //not allowed https://2ality.com/2020/05/records-tuples-first-look.html https://2ality.com/2020/05/records-tuples-first-look.html
afiori 6y ago
const is useful when multiple part of a program might refer to the same object/value, blocking rebindings is what you need to keep all the references in sync.