immutability

Is there a way to efficiently share or move .NET objects across AppDomains? I realize that the intent of AppDomains is to provide isolation - however I have a case where I need to move a relatively large, cached set of immutable objects that are expensive to compute and create. At the moment, I have a serialization approach that works, but is rather slow. You cannot move an object across an AppDomain without serializing it. That is the main point of an AppDomain - you can almost think of it as a completely separate process. This is where MarshallByRefObject comes into play. It allows you to

I have below a description of a data structure I need and I want to implement it using immutable data structures. I'm trying to determine... is there an existing data structure out there that will support what I'm trying to do here or do I need to create one--and if I need to create it, what would be a good place to start (building blocks)? I have a steady stream of incoming values of a certain type. I want to add them to a persistent/immutable data structure to hold a history of them, and on each add, it will review the history and determine if one or more oldest items will be removed (for

I was reading an article that said that Java strings are not completely immutable. However, in the article's sample code that modifies the string, it makes a call to string.toUpperCase().toCharArray(), which returns a new string. So what's the purpose of going through the process of changing the string if you call toUpperCase() anyway? Here is the code: public static void toUpperCase(String orig) { try { Field stringValue = String.class.getDeclaredField("value"); stringValue.setAccessible(true); stringValue.set(orig, orig.toUpperCase().toCharArray()); } catch (Exception ex){} } Also, I noticed

The documentation for HttpClient states the following about immutability: Interceptors exist to examine and mutate outgoing requests and incoming responses. However, it may be surprising to learn that the HttpRequest and HttpResponse classes are largely immutable. This is for a reason: because the app may retry requests, the interceptor chain may process an individual request multiple times. If requests were mutable, a retried request would be different than the original request. Immutability ensures the interceptors see the same request for each try. I find it hard to understand this

I've been fetching rows from a WebSQL DB, and the returned rows seems to be readonly. db.readTransaction( function(t1) { t1.executeSql( "SELECT * FROM Foo WHERE id = ?", [1], function(t2, resultSet){ var foo = resultSet.rows.item(0); console.log("before: " + foo.col1); foo.col1 = "new value"; console.log("after: " + foo.col1); console.log("sealed? " + Object.isSealed(foo)); console.log("frozen? " + Object.isFrozen(foo)); } ); } ); It prints: before: old value after: old value sealed? false frozen? false I had to manually clone the row to be able to modify it. How is this possible? How can an

Many questions/answers have indicated that if a class object has a final field and no reference to it is exposed to any other thread during construction, then all threads are guaranteed to see the value written to the field once the constructor completes. They have also indicated that storing into a final field a reference to a mutable object which has never been accessed by outside threads will ensure that all mutations which have been made to the object prior to the store will be visible on all threads which access the object via the field. Unfortunately, neither guarantee applies to writes