Timeline for Immutability across programming languages
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Aug 29 at 20:11 | history | suggested | Bergi | CC BY-SA 4.0 |
See comments
|
| Aug 27 at 11:48 | comment | added | kaya3 |
@Ghassen Consider "similar" code like x = y then y.foo = 20, where the second statement changes the value of x even though it does not mention x.
|
|
| Aug 27 at 10:00 | comment | added | Ghassen | Thank you for your answer. I didn't understand something when you said, "You can't do something like 10 = 20 to change the value of x. The 10 is immutable." The expression 10 = 20 didn't make sense to me. Why would we consider if it changes the value of x if it doesn't have anything to do with x? (at least from what I understand) | |
| Aug 27 at 0:36 | comment | added | Bergi | @Flater No, I was trying to say what Kaya3 has expressed much better now. A literal is a type of expression in the language grammar, not a runtime value. | |
| Aug 26 at 23:02 | comment | added | Flater | @Bergi: I get the feeling you're getting caught up on the distinction between what Karl was trying to say and what you believe would have been better to say. I'm with Bart that Karl intended to refer to literals. I also don't fully agree with Karl's point (as per my first comment here) but he was referring to literals (on the implicit notion that all literals are value types, which I agree with you is not entirely correct due to some edge cases). | |
| Aug 26 at 20:13 | comment | added | kaya3 | Many languages have literal syntax for mutable objects, such as lists and dictionaries. "Primitive" is the more correct word here, and the edit should not have been made. "Literal" is a purely syntactic category; literals are tokens in the source code, not values which exist at runtime, so it doesn't strictly make sense to say that a literal itself is immutable or mutable. | |
| Aug 26 at 19:26 | comment | added | Buffy | Way, way back in Fortran 4 there was a way to change 10 to 20 using "Blank Common." The problem was that the literal 10 was stored as a reference to a value in common. | |
| Aug 26 at 16:29 | review | Suggested edits | |||
| S Aug 29 at 20:11 | |||||
| Aug 26 at 16:27 | comment | added | Bergi |
@Flater Ah, yes, "value type" is more accurate than "primitive type", I conflated the two because in most languages they are the same set of types (but one could imagine a mutable primitive "semaphore" type or something). However I still disagree with the term "literal", which does not refer to a value but rather the notation for a value in code. And while many literals produce immutable values when evaluated, not all of them do, like {} in JS or "str" in C.
|
|
| Aug 26 at 14:34 | comment | added | Flater | @Bergi: Whether they're primitives is irrelevant, the only thing that matters is that they're a value type. Not a value, a value type. Those are two distinct concepts. A reference is in and of itself a value as well. It is the type's nature (i.e. reference type or value type) that provides the distinction between the behaviors, not the value itself that is being assigned. | |
| Aug 26 at 14:31 | comment | added | Flater |
@Bergi In the context of code and syntax a literal refers to an explicit value. Bart is correct. Karl's mention of 10=20 is specifically using literals, not value-type variables of any kind.
|
|
| Aug 26 at 8:46 | comment | added | Bergi | @Flater I don't think there's a problem with "primitives like numbers and strings", it means "primitive values like number and string values" | |
| Aug 26 at 8:46 | comment | added | Bergi |
@BartVanIngenSchenau "I think "literal" was the word you were looking for for things like 10 or "Hello"" - no, the term "literal" refers to an expression in source code, whereas the sentence needs to refer to values.
|
|
| Aug 26 at 7:12 | history | edited | Bart van Ingen Schenau | CC BY-SA 4.0 |
I think "literal" was the word you were looking for for things like 10 or "Hello"
|
| Aug 26 at 4:13 | comment | added | Flater | That aside, still a +1 from me on pointing out the distinction between variable and object mutability. | |
| Aug 26 at 4:10 | comment | added | Flater | I agree with the distinction but I think the conclusion misses the mark on its phrasing. Immutability of variables is a relevant consideration when dealing with value types (and indeed very different from an object being immutable or not). However, I find "primitives like numbers and strings are immutable" a bit of a nonsensical point to bring up. Types (which is what you're referring to with "primitives") have no concept of mutability. Mutation happens on state, which means that you need to be thinking of (reference and value type) variables and (reference type) objects. | |
| Aug 26 at 1:30 | history | answered | Karl Bielefeldt | CC BY-SA 4.0 |