immutability

What is the reason why Wrapper classes (like Integer, Double, etc.) don't have a setter for their inner primitive value ? I am asking this because that kind of functionality would have simplified calculus, and have made the Java language a little more flexible . Let me give you some examples. 1) Let's take the following example: Integer x = new Integer(5); x++; The previous code behind the scenes is performing autoboxing . Something like: int x_tmp = x.intValue(); x_tmp++; x = new Integer(x_tmp); // Yes that's a new memory allocation Because of this problem doing calculus on Wrapper is slower

In reading John Palmer's answer to What is the difference between mutable values and immutable value redefinition? , John notes that This sort of redefinition will only work in fsi. In working with F# Interactive (fsi) I guess I subconsciously knew it, but never paid attention to it. Now that it is apparent, why the difference? More specifically please explain how the internals are different between fsi and the compiler such that this occurs by design or result of differences? If the answer can elaborate on the internal structures that hold the bindings that would be appreciated. The semantics

I have following reducer code in my react-redux app: case 'TOGGLE_CLIENT_SELECTION': const id = action.payload.id; let newState = Object.assign({}, state); newState.list.forEach((client) => { if (client.id == id) client.selected = !client.selected; }); console.log(state.list[0].selected + ' - ' + newState.list[0].selected) return newState; If I got it right - Object.assign creates brand new object, but console.log displays "true - true" of "false - false". Any thoughts why it behaves like this and how can I avoid this behavior? True, but it's not a deep copy. The new object contains a

I am encountering what seems to be a very weird bug in ImmutableArray<> (with BCL Immutable collections v1.0.12.0, runtime .NET 4.5): I have the following two identical structs exactly in the same source file under the same namespace: public struct WeightedComponent { public readonly IComponent Component; public readonly decimal Weight; public WeightedComponent(IComponent component, decimal weight) { this.Component = component; this.Weight = weight; } } public struct WeightedComponent2 { public readonly IComponent Component; public readonly decimal Weight; public WeightedComponent2(IComponent

If you have an immutable list, you expect it to always return a reference to the same object when you ask for, say list.get(0) My question is, would you expect to be able to mutate the object and have the mutation reflected next time you get it from the list? It depends on the context. In a general purpose library, all we should assume is that the list is immutable. Changes to the elements in the list would be reflected to all callers, as a direct consequence of returning the same reference each time. However, if this is a specialized immutable tree (or whatever), and is documented as such

This question already has an answer here: Immutability of Strings in Java 26 answers String s = ...; s = s.substring(1); Is this possible? I thought you can't change a String object in Java. String objects are immutable. String references , however, are mutable. Above, s is a reference. String objects are immutable, meaning that the value of the instance referred to by s cannot change. Your code does not mutate the instance. Rather, it changes the s reference to refer to a new string instance. For example: String a = "1"; String b = a; a = "2"; After executing this code, b is still "1" . The

I read several related questions, but none of them explains ways of safe publication of the Holder. I am still confused about example from Java Concurrency in Practice, section 3.5: There is the class Holder: public Holder { private int n; public Holder(int n) { this.n = n }; public void assertSanity() { if(n != n) throw new AssertionError("This statement is false."); } } and its unsafe publication: //unsafe publication public Holder holder; public void initialize() { holder = new Holder(42); } The AssertionError could be thrown and I agree. The authors write that it is because of unsafe

I want to convert generator or iterator to list recursively. I wrote a code in below, but it looks naive and ugly, and may be dropped case in doctest. Q1. Help me good version. Q2. How to specify object is immutable or not? import itertools def isiterable(datum): return hasattr(datum, '__iter__') def issubscriptable(datum): return hasattr(datum, "__getitem__") def eagerlize(obj): """ Convert generator or iterator to list recursively. return a eagalized object of given obj. This works but, whether it return a new object, break given one. test 1.0 iterator >>> q = itertools.permutations('AB', 2)