immutability

问题 Consider the following code, which provokes CA2104: Do not declare read only mutable reference types. public class Test { // This provokes CA2104: "Do not declare read only mutable reference types". protected readonly ImmutableClass ImmutableMember; } public class ImmutableClass { } Does anyone know of a way to mark a class as immutable in a way that would suppress warning CA2104? I tried decorating MutableClass with [ImmutableObject(true)] with no hope of success (since that attribute is

问题 I was testing the ImmutableObjectAttribute attribute just for curiosity to see if I could gain some beneffits applying it, or if it was just for semantic decoration... ImmutableObjectAttribute Class Specifies that an object has no subproperties capable of being edited. So I have this class: <ImmutableObject(True)> Public Class TestClass <ImmutableObject(True)> Public sb As StringBuilder Public Sub New() sb = New StringBuilder End Sub End Class And I've tested with this code: Dim obj As New

问题 What's the difference between: class Person(name: String, age: Int) { def say = "My name is " + name + ", age " + age } and class Person(val name: String, val age: Int) { def say = "My name is " + name + ", age " + age } Can I declare parameters as var s, and change their values later? For instance, class Person(var name: String, var age: Int) { age = happyBirthday(5) def happyBirthday(n: Int) { println("happy " + n + " birthday") n } } 回答1: For the first part the answer is scope: scala>

问题 Is there a better way of doing this... MyString.Trim().Replace("&", "and").Replace(",", "").Replace(" ", " ") .Replace(" ", "-").Replace("'", "").Replace("/", "").ToLower(); I've extended the string class to keep it down to one job but is there a quicker way? public static class StringExtension { public static string clean(this string s) { return s.Replace("&", "and").Replace(",", "").Replace(" ", " ") .Replace(" ", "-").Replace("'", "").Replace(".", "") .Replace("eacute;", "é").ToLower(); }

问题 I am not sure why strings and tuples were made to be immutable; what are the advantages and disadvantage of making them immutable? 回答1: One is performance: knowing that a string is immutable makes it easy to lay it out at construction time — fixed and unchanging storage requirements. This is also one of the reasons for the distinction between tuples and lists. This also allows the implementation to safely reuse string objects. For example, the CPython implemenation uses pre-allocated objects

问题 I have a class X which holds Employee object. I want to make the class X as immutable. Now even if I declare the Employee object as final the Employee class exists independently and people can access the setter methods of that particular employee object. Is it possible to have a normal class Employee and another immutable class X which holds Employee but we cannot change value of Employee once it is assigned? public final class X { private final Employee emp; public X (Employee e){ this.emp =

问题 I have a multi-threaded application in Python where threads are reading very large (so I cannot copy them to thread-local storage) dicts (read from disk and never modified). Then they process huge amounts of data using the dicts as read-only data: # single threaded d1,d2,d3 = read_dictionaries() while line in stdin: stdout.write(compute(line,d1,d2,d3)+line) I am trying to speed this up by using threads, which would then each read its own input and write its own output, but since the dicts are

问题 I have a multi-threaded application in Python where threads are reading very large (so I cannot copy them to thread-local storage) dicts (read from disk and never modified). Then they process huge amounts of data using the dicts as read-only data: # single threaded d1,d2,d3 = read_dictionaries() while line in stdin: stdout.write(compute(line,d1,d2,d3)+line) I am trying to speed this up by using threads, which would then each read its own input and write its own output, but since the dicts are

问题 Hi was reading about that a string is thread safe because it is immutable. For example i do: String a = "test"; One thread uses this variable. But another thread could still also use this variable and change it: a = a + "something"; So it would change or not? If it would be volatile, i would get it, that it can just be used by one thread at a time. But immutabilty doesnt guarantee me this!? 回答1: You're not changing the object pointed by a , but where a points to: String a = "test"; here a

问题 I am new in Scala world and now I am reading the book called "Scala in Action" (by Nilanjan Raychaudhuri), namely the part called "Mutable object need to be invariant" on page 97 and I don't understand the following part which is taken directly from the mentioned book. Assume ListBuffer is covariant and the following code snippet works without any compilation problem: scala> val mxs: ListBuffer[String] = ListBuffer("pants") mxs: scala.collection.mutable.ListBuffer[String] = ListBuffer(pants)