immutability

问题 First, let the code speak: #[derive(Debug)] struct Bar; #[derive(Debug)] struct Qux { baz: bool } #[derive(Debug)] struct Foo { bars: Vec<Bar>, qux: Qux, } impl Foo { fn get_qux(&mut self) -> &mut Qux { &mut self.qux } fn run(&mut self) { // 1. Fails: let mut qux = self.get_qux(); // 2. Works: // let mut qux = &mut Qux { baz: false }; // 3. Works: // let mut qux = &mut self.qux; let qux_mut = &mut qux; qux_mut.baz = true; for bar in &self.bars { println!(\"{:?}\", bar); } } } fn main() {

问题 Are there any guidelines in Scala on when to use val with a mutable collection versus using var with an immutable collection? Or should you really aim for val with an immutable collection? The fact that there are both types of collection gives me a lot of choice, and often I don\'t know how to make that choice. 回答1: Pretty common question, this one. The hard thing is finding the duplicates. You should strive for referential transparency . What that means is that, if I have an expression "e",

问题 I am working on creating an immutable class. I have marked all the properties as read-only. I have a list of items in the class. Although if the property is read-only the list can be modified. Exposing the IEnumerable of the list makes it immutable. I wanted to know what is the basic rules one has to follow to make a class immutable ? 回答1: I think you're on the right track - all information injected into the class should be supplied in the constructor all properties should be getters only if

问题 I have this API function: public ResultEnum DoSomeAction(string a, string b, DateTime c, OtherEnum d, string e, string f, out Guid code) I don\'t like it. Because parameter order becomes unnecessarily significant. It becomes harder to add new fields. It\'s harder to see what\'s being passed around. It\'s harder to refactor method into smaller parts because it creates another overhead of passing all the parameters in sub functions. Code is harder to read. I came up with the most obvious idea:

问题 Is it possible to create a class with an immutable reference to a partner object, or does it have to be a var that I assign after creation? e.g. class PairedObject (p: PairedObject, id: String) { val partner: PairedObject = p // but I need ref to this object to create p! } or similarly how could I instantiate the following pair? class Chicken (e: Egg) { val offspring = e } class Egg (c: Chicken) { val mother = c } 回答1: Here is a complete solution to the Chicken/Egg problem: class Chicken (e:

问题 Having a friendly debate with a co-worker about this. We have some thoughts about this, but wondering what the SO crowd thinks about this? 回答1: One reason is there is no CLR support for a readonly local. Readonly is translated into the CLR/CLI initonly opcode. This flag can only be applied to fields and has no meaning for a local. In fact, applying it to a local will likely produce unverifiable code. This doesn't mean that C# couldn't do this. But it would give two different meanings to the

问题 I\'ve recently been learning about functional programming (specifically Haskell, but I\'ve gone through tutorials on Lisp and Erlang as well). While I found the concepts very enlightening, I still don\'t see the practical side of the \"no side effects\" concept. What are the practical advantages of it? I\'m trying to think in the functional mindset, but there are some situations that just seem overly complex without the ability to save state in an easy way (I don\'t consider Haskell\'s monads

问题 I learnt that in some immutable classes, __new__ may return an existing instance - this is what the int , str and tuple types sometimes do for small values. But why do the following two snippets differ in the behavior? With a space at the end: >>> a = \'string \' >>> b = \'string \' >>> a is b False Without a space: >>> c = \'string\' >>> d = \'string\' >>> c is d True Why does the space bring the difference? 回答1: This is a quirk of how the CPython implementation chooses to cache string

问题 In an effort to reduce mutability, should we rather use public void setValues(String[] newVals) { this.vals = ( newVals == null ? null : newVals.clone() ); } or public void setValues(String[] newVals) { this.vals = ( newVals == null ? null : Arrays.copyOf(newVals, newVals.length) ); } 回答1: Update using jmh Using jmh, I get similar results, except that clone seems to be marginally better. Original post I ran a quick test for performance: clone , System.arrayCopy and Arrays.copyOf have very

问题 Once I studied about the advantage of a string being immutable because of something to improve performace in memory. Can anybody explain this to me? I can\'t find it on the Internet. 回答1: Immutability (for strings or other types) can have numerous advantages: It makes it easier to reason about the code, since you can make assumptions about variables and arguments that you can't otherwise make. It simplifies multithreaded programming since reading from a type that cannot change is always safe