immutability

How to get an arbitrary element from a frozenset?

由 旧时模样 提交于 2019-12-03 23:55:23
问题 I would like to get an element from a frozenset (without modifying it, of course, as frozenset s are immutable). The best solution I have found so far is: s = frozenset(['a']) iter(s).next() which returns, as expected: 'a' In other words, is there any way of 'popping' an element from a frozenset without actually popping it? 回答1: (Summarizing the answers given in the comments) Your method is as good as any, with the caveat that, from Python 2.6, you should be using next(iter(s)) rather than

Are all final class immutable?

由 我与影子孤独终老i 提交于 2019-12-03 23:43:20
Are all final classes in Java immutable. String and Integer both are final classes and both are immutable i beleive. No - a final class means you cannot inherit from it. It has nothing to do with mutability. The following class is final yet mutable: public final class FinalMutable { int value; public void setValue(int v) { value=v; } public int getValue() { return value; } } No, final means the class can not be extended. It says nothing about mutability. For example: final class MutInt { public int modifyMe; } There is no keyword for immutability, it's more like a design pattern. EDIT: This

How do I make a struct immutable?

由 早过忘川 提交于 2019-12-03 23:29:07
问题 All over Stack Overflow and the internet I see that it is a good design principle to keep structs immutable. Unfortunately, I never see any implementation that actually causes these structs to be truly immutable. Assuming that a struct does not have any reference types inside it, how do I actually make a struct immutable? That is, how do I prevent the mutation of any of its primitive field (perhaps by a compile-time/runtime exception)? I wrote a simple test attempting make a struct immutable,

How can I avoid mutable variables in Scala when using ZipInputStreams and ZipOutpuStreams?

由 不羁岁月 提交于 2019-12-03 23:04:16
I'm trying to read a zip file, check that it has some required files, and then write all valid files out to another zip file. The basic introduction to java.util.zip has a lot of Java-isms and I'd love to make my code more Scala-native. Specifically, I'd like to avoid the use of vars . Here's what I have: val fos = new FileOutputStream("new.zip"); val zipOut = new ZipOutputStream(new BufferedOutputStream(fos)); while (zipIn.available == 1) { val entry = zipIn.getNextEntry if (entryIsValid(entry)) { zipOut.putNewEntry(new ZipEntry("subdir/" + entry.getName()) // read data into the data Array

How to Prove Immutabiltiy of String in C#?

由 假装没事ソ 提交于 2019-12-03 17:18:04
问题 In my last c# interview, I was asked to prove immutability of C# string,I know what is meant by immutability of c# string,But is it possible to prove immutability of c# string through code ? can i have a sample code snippet please. Thanks in advance 回答1: I can prove that a string is not immutable. All I need to do is to show some code which mutates a string , like so: using System; using System.Runtime.InteropServices; namespace Demo { class Program { static void Main(string[] args) { const

When to use mutable vs immutable classes in Scala

由 不羁的心 提交于 2019-12-03 16:58:10
问题 Much is written about the advantages of immutable state, but are there common cases in Scala where it makes sense to prefer mutable classes? (This is a Scala newbie question from someone with a background in "classic" OOP design using mutable classes.) For something trivial like a 3-dimensional Point class, I get the advantages of immutability. But what about something like a Motor class, which exposes a variety of control variables and/or sensor readings? Would a seasoned Scala developer

Immutable objects in PHP?

由 倖福魔咒の 提交于 2019-12-03 16:44:42
问题 Is it a good idea to create objects that cannot be changed in PHP? For example a date object which has setter methods, but they will always return a new instance of the object (with the modified date). Would these objects be confusing to other people that use the class, because in PHP you usually expect the object to change? Example $obj = new Object(2); $x = $obj->add(5); // 7 $y = $obj->add(2); // 4 回答1: An immutable object cannot be change after its initial creation so having setter

Can we get access to the F# copy and update feature from c#?

由 送分小仙女□ 提交于 2019-12-03 16:16:09
问题 For example in F# we can define type MyRecord = { X: int; Y: int; Z: int } let myRecord1 = { X = 1; Y = 2; Z = 3; } and to update it I can do let myRecord2 = { myRecord1 with Y = 100; Z = 2 } That's brilliant and the fact that records automatically implement IStructuralEquality with no extra effort makes me wish for this in C#. However Perhaps I can define my records in F# but still be able to perform some updates in C#. I imagine an API like MyRecord myRecord2 = myRecord .CopyAndUpdate(p=>p

Why won't declaring an array final make it immutable in Java?

由 丶灬走出姿态 提交于 2019-12-03 15:48:46
问题 Why won't declaring an array final make it immutable in Java? Doesn't declaring something final mean it can't be changed? From question related to immutable array it's clear that declaring an array final doesn't make it unchangeable. The following is possible. final int[] array = new int[] {0, 1, 2, 3}; array[0] = 42; My question is: What is the function of declaring final here then? 回答1: final is only about the reference that is marked by it; there is no such thing as an immutable array in

Functional way to implement a thread safe shared counter

由 不羁岁月 提交于 2019-12-03 15:28:12
I'm relatively new to Scala and functional programming, and I like the idea that using immutable objects I can avoid many thread safety pitfalls. One thing still haunts me, and it's the classical example used to teach thread safety - the shared counter. I was wondering if it would be possible to implement a thread-safe counter (a request counter in this example), using immutable objects, and functional concepts, and avoid synchronization completely. So for reference here are first the classical mutable versions of the counter (excuse me for the public member variable, just for brevity of the
订阅 immutability