immutability

I am a newbie in Objective C and I was wondering what is the best way to define an immutable class in Objective-C (like NSString for example). I want to know what are the basic rules one has to follow to make a class immutable. I think that : setters shouldn't be provided if properties are used, they should be readonly to "disable" Key Value Coding , accessInstanceVariablesDirectly must be override and return NO Did I forget something ? Thanks The first and foremost thing you should do is to include usage comments in your .h file that explain that this is an immutable class, along with the

Why are int s and double s immutable? What is the purpose of returning a new object each time you want to change the value? The reason I ask is because I'm making a class: BoundedInt , which has a value and an upper and lower bound. So I was wondering: should I make this type immutable too? (Or should it be a struct ?) Firstly: What is the purpose of returning a new object each time you want to change the value? I think you might be mistaken about how value types work. This isn't some costly operation like you may be imagining; it's simply the overwriting of data (as opposed to, e.g., dynamic

I was reading through Item 15 of Effective Java by Joshua Bloch. Inside Item 15 which speaks about 'minimizing mutability' he mentions five rules to make objects immutable. One of them is is to make all fields final . Here is the rule : Make all fields final : This clearly expresses your intent in a manner that is enforced by the system. Also, it is necessary to ensure correct behavior if a reference to a newly created instance is passed from one thread to another without synchronization, as spelled out in the memory model [JLS, 17.5; Goetz06 16]. I know that String class is an example of a

I don't get how can something as a Set be immutable and still have an acceptable performance. From what I've read in F# Sets internally use Red Black Trees as their implementation. If each time we want to add something new to a Red Black Tree we have to basically recreate it, how can it have ever good performance? What am I missing here? Although I am asking this for F#'s Sets, I think this is as relevant in any other language which has or uses immutable data structures. Thanks Almost all immutable collections are some form of balanced tree. To create a new tree, you have to reallocate nodes

I'm currently learning functional programming in my spare time with Scala, and I have an idle newbie question. I can see the elegance of having immutable objects when doing something like calculating a Haar wavelet transform - i.e. when the data itself being represented by the objects doesn't change. But I saw a blog where someone had a small game as an example when demonstrating immutability. If a creature object recieved damage, it didn't change its state - it returned a new creature object with the new hitpoints and a new "aggro towards X" flag. But if we were to design something like a

I want to make sure that I correctly understand the 'Effectively Immutable Objects' behavior according to Java Memory Model. Let's say we have a mutable class which we want to publish as an effectively immutable: class Outworld { // This MAY be accessed by multiple threads public static volatile MutableLong published; } // This class is mutable class MutableLong { private long value; public MutableLong(long value) { this.value = value; } public void increment() { value++; } public long get() { return value; } } We do the following: // Create a mutable object and modify it MutableLong val = new

As I figured out, variables in Haskell are immutable (thus, they are not really `variables'). In this case, if we have a complex and big data structure, like a red-black tree, how are we supposed to implement operations that actually change the data structure? Create a copy of the tree each time an element is inserted or deleted? Yes, the solution is to return a new data structure which represents the modified value, however there is no requirement to copy the entire structure for your example (red-black trees) since you can just copy the nodes on the path from the root to the inserted node.

In Real World Haskell , there is a section titled "Life without arrays or hash tables" where the authors suggest that list and trees are preferred in functional programming, whereas an array or a hash table might be used instead in an imperative program. This makes sense, since it's much easier to reuse part of an (immutable) list or tree when creating a new one than to do so with an array. So my questions are: Are there really significantly different usage patterns for data structures between functional and imperative programming? If so, is this a problem? What if you really do need a hash

So I started learning React a week ago and I inevitably got to the problem of state and how components are supposed to communicate with the rest of the app. I searched around and Redux seems to be the flavor of the month. I read through all the documentation and I think it's actually a pretty revolutionary idea. Here are my thoughts on it: State is generally agreed to be pretty evil and a large source of bugs in programming. Instead of scattering it all throughout your app Redux says why not just have it all concentrated in a global state tree that you have to emit actions to change? Sounds