immutability

I am learning scala and as a good student I try to obey all rules I found. One rule is: IMMUTABILITY!!! So I have tried to code everything with immutable data structures and vals, and sometimes this is really hard. But today I thought to myself: the only important thing is that the object/class should have no mutable state. I am not forced to code all methods in an immutable style, because these methods don't affect each other. My Question: Am I correct or are there any problems/disadvantages I dont see ? EDIT: Code example for aishwarya: def logLikelihood(seq: Iterator[T]): Double = { val

Anyone have any opinions on whether or not IEquatable<T> or IComparable<T> should generally require that T is sealed (if it's a class )? This question occurred to me since I'm writing a set of base classes intended to aid in the implementation of immutable classes. Part of the functionality which the base class is intended to provide is automatic implementation of equality comparisons (using the class's fields together with attributes which can be applied to fields to control equality comparisons). It should be pretty nice when I'm finished - I'm using expression trees to dynamically create a

Is there a simple way to create an immutable NumPy array? If one has to derive a class from ndarray to do this, what's the minimum set of methods that one has to override to achieve immutability? You can make a numpy array unwriteable: a = np.arange(10) a.flags.writeable = False a[0] = 1 # Gives: RuntimeError: array is not writeable Also see the discussion in this thread: http://mail.scipy.org/pipermail/numpy-discussion/2008-December/039274.html and the documentation: http://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.flags.html 来源： https://stackoverflow.com/questions/5541324

I frequently read that struct s should be immutable - aren't they by definition? Do you consider int to be immutable? int i = 0; i = i + 123; Seems okay - we get a new int and assign it back to i . What about this? i++; Okay, we can think of it as a shortcut. i = i + 1; What about the struct Point ? Point p = new Point(1, 2); p.Offset(3, 4); Does this really mutate the point (1, 2) ? Shouldn't we think of it as a shortcut for the following with Point.Offset() returning a new point? p = p.Offset(3, 4); The background of this thought is this - how can a value type with no identity be mutable?

I have over the course of a few projects developed a pattern for creating immutable (readonly) objects and immutable object graphs. Immutable objects carry the benefit of being 100% thread safe and can therefore be reused across threads. In my work I very often use this pattern in Web applications for configuration settings and other objects that I load and cache in memory. Cached objects should always be immutable as you want to guarantee they are not unexpectedly changed. Now, you can of course easily design immutable objects as in the following example: public class SampleElement { private

I have implemented a few Java applications now, only desktop applications so far. I prefer to use immutable objects for passing the data around in the application instead of using objects with mutators (setters and getters ), also called JavaBeans. But in the Java world, it seems to be much more common to use JavaBeans, and I can't understand why I should use them instead. Personally the code looks better if it only deals with immutable objects instead of mutate the state all the time. Immutable objects are also recommended in Item 15: Minimize mutability , Effective Java 2ed . If I have an

I have some big (more than 3 fields) objects that can and should be immutable. Every time I run into that case I tend to create constructor abominations with long parameter lists. It doesn't feel right, it is hard to use, and readability suffers. It is even worse if the fields are some sort of collection type like lists. A simple addSibling(S s) would ease the object creation so much but renders the object mutable. What do you guys use in such cases? I'm on Scala and Java, but I think the problem is language agnostic as long as the language is object oriented. Solutions I can think of: