Search Results

Search found 325 results on 13 pages for 'immutable'.

Page 1/13 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Is there any functional difference between immutable value types and immutable reference types?

    - by Kendall Frey
    Value types are types which do not have an identity. When one variable is modified, other instances are not. Using Javascript syntax as an example, here is how a value type works. var foo = { a: 42 }; var bar = foo; bar.a = 0; // foo.a is still 42 Reference types are types which do have an identity. When one variable is modified, other instances are as well. Here is how a reference type works. var foo = { a: 42 }; var bar = foo; bar.a = 0; // foo.a is now 0 Note how the example uses mutatable objects to show the difference. If the objects were immutable, you couldn't do that, so that kind of testing for value/reference types doesn't work. Is there any functional difference between immutable value types and immutable reference types? Is there any algorithm that can tell the difference between a reference type and a value type if they are immutable? Reflection is cheating. I'm wondering this mostly out of curiosity.

    Read the article

  • Do immutable objects and DDD go together?

    - by SnOrfus
    Consider a system that uses DDD (as well: any system that uses an ORM). The point of any system realistically, in nearly every use case, will be to manipulate those domain objects. Otherwise there's no real effect or purpose. Modifying an immutable object will cause it to generate a new record after the object is persisted which creates massive bloat in the datasource (unless you delete previous records after modifications). I can see the benefit of using immutable objects, but in this sense, I can't ever see a useful case for using immutable objects. Is this wrong?

    Read the article

  • Do immutable objects and DDD go together?

    - by SnOrfus
    Consider a system that uses DDD (as well: any system that uses an ORM). The point of any system realistically, in nearly every use case, will be to manipulate those domain objects. Otherwise there's no real effect or purpose. Modifying an immutable object will cause it to generate a new record after the object is persisted which creates massive bloat in the datasource (unless you delete previous records after modifications). I can see the benefit of using immutable objects, but in this sense, I can't ever see a useful case for using immutable objects. Is this wrong?

    Read the article

  • Best way to define an immutable class in Objective C

    - by Patrick Marty
    Hi, I am a newbie in Objective C and I was wondering what is the best way to define an immutable class in Objective-C (like NSString for example). I want to know what are the basic rules one has to follow to make a class immutable. I think that : setters shouldn't be provided if properties are used, they should be readonly accessInstanceVariablesDirectly must be override and return NO Did I forget something ? Thanks

    Read the article

  • Immutable Method Java

    - by Chris Okyen
    In Java, there is the final keyword in lieu of the const keyword in c and c++. In the latter languages their is mutable and immutable methods such as stated in one answer by Johannes Schaub - litb the question how-many-and-which-are-the-uses-of-const-in-ce Use const to tell others methods won't change the logical state of this object. struct SmartPtr { int getCopies() const { return mCopiesMade; } }ptr1; ... int var = ptr.getCopies(); // returns mCopiesMade and is specified that to not modify objects state. How is this performed in Java?

    Read the article

  • Immutable Method in Java

    - by Chris Okyen
    In Java, there is the final keyword in lieu of the const keyword in C and C++. In the latter languages there are mutable and immutable methods such as stated in the answer by Johannes Schaub - litb to the question How many and which are the uses of “const” in C++? Use const to tell others methods won't change the logical state of this object. struct SmartPtr { int getCopies() const { return mCopiesMade; } }ptr1; ... int var = ptr.getCopies(); // returns mCopiesMade and is specified that to not modify objects state. How is this performed in Java?

    Read the article

  • Mutable class as a child of an immutable class

    - by deamon
    I want to have immutable Java objects like this (strongly simplyfied): class Immutable { protected String name; public Immutable(String name) { this.name = name; } public String getName() { return name; } } In some cases the object should not only be readable but mutable, so I could add mutability through inheritance: public class Mutable extends Immutable { public Mutable(String name) { super(name); } public void setName(String name) { super.name = name; } } While this is technically fine, I wonder if it conforms with OOP and inheritance that mutable is also of type immutable. I want to avoid the OOP crime to throw UnsupportedOperationException for immutable object, like the Java collections API does. What do you think? Any other ideas?

    Read the article

  • Java: immutable Stack?

    - by HH
    I chose to use Stacks and Tables before knowing Collections has immutable empty things only for Set, Map and List. Because the size of table does not change after its init: Integer[] table = new Intger[0] I can use the zero-witdh table as an empty table. But I cannot use final or empty Stack to get immutable Stack: No immutability to Stack with Final import java.io.*; import java.util.*; public class TestStack{ public static void main(String[] args) { final Stack<Integer> test = new Stack<Integer>(); Stack<Integer> test2 = new Stack<Integer>(); test.push(37707); test2.push(80437707); //WHY is there not an error to remove an elment // from FINAL stack? System.out.println(test.pop()); System.out.println(test2.pop()); } } Java Api 5 for list interface shows that Stack is an implementing class for list and arraylist, here. The java.coccurrent pkg does not have any immutable Stack data structure. From Stack to some immutable data structure How to get immutable Stack data structure? Can I box it with list? Should I switch my current implementatios from stacks to Lists to get immutable? Which immutable data structure is Very fast with about similar exec time as Stack?

    Read the article

  • immutable strings vs std::string

    - by Caspin
    I've recent been reading about immutable strings, here and here as well some stuff about why D chose immutable strings. There seem to be many advantages. trivially thread safe more secure more memory efficient in most use cases. cheap substrings (tokenizing and slicing) Not to mention most new languages have immutable strings, D2.0, Java, C#, Python, Ruby, etc. Would C++ benefit from immutable strings? Is it possible to implement an immutable string class in c++ (or c++0x) that would have all of these advantages?

    Read the article

  • If immutable objects are good, why do people keep creating mutable objects?

    - by Vinoth Kumar
    If immutable objects are good,simple and offers benefits in concurrent programming why do programmers keep creating mutable objects? I have four years of experience in Java programming and as I see it, the first thing people do after creating a class is generate getters and setters in the IDE (thus making it mutable). Is there a lack of awareness or can we get away with using mutable objects in most scenarios?

    Read the article

  • Immutable Dictionary overhead?

    - by Roger Alsing
    When using immutable dictionaries in F# , how much overhead is there when adding / removing entries? Will it treat entire buckets as immutable and clone those and only recreate the bucket whos item has changed? Even if that is the case, it seems like there is alot of copying that needs to be done in order to create the new dictionary(?)

    Read the article

  • What's the best name for a non-mutating "add" method on an immutable collection?

    - by Jon Skeet
    Sorry for the waffly title - if I could come up with a concise title, I wouldn't have to ask the question. Suppose I have an immutable list type. It has an operation Foo(x) which returns a new immutable list with the specified argument as an extra element at the end. So to build up a list of strings with values "Hello", "immutable", "world" you could write: var empty = new ImmutableList<string>(); var list1 = empty.Foo("Hello"); var list2 = list1.Foo("immutable"); var list3 = list2.Foo("word"); (This is C# code, and I'm most interested in a C# suggestion if you feel the language is important. It's not fundamentally a language question, but the idioms of the language may be important.) The important thing is that the existing lists are not altered by Foo - so empty.Count would still return 0. Another (more idiomatic) way of getting to the end result would be: var list = new ImmutableList<string>().Foo("Hello"); .Foo("immutable"); .Foo("word"); My question is: what's the best name for Foo? EDIT 3: As I reveal later on, the name of the type might not actually be ImmutableList<T>, which makes the position clear. Imagine instead that it's TestSuite and that it's immutable because the whole of the framework it's a part of is immutable... (End of edit 3) Options I've come up with so far: Add: common in .NET, but implies mutation of the original list Cons: I believe this is the normal name in functional languages, but meaningless to those without experience in such languages Plus: my favourite so far, it doesn't imply mutation to me. Apparently this is also used in Haskell but with slightly different expectations (a Haskell programmer might expect it to add two lists together rather than adding a single value to the other list). With: consistent with some other immutable conventions, but doesn't have quite the same "additionness" to it IMO. And: not very descriptive. Operator overload for + : I really don't like this much; I generally think operators should only be applied to lower level types. I'm willing to be persuaded though! The criteria I'm using for choosing are: Gives the correct impression of the result of the method call (i.e. that it's the original list with an extra element) Makes it as clear as possible that it doesn't mutate the existing list Sounds reasonable when chained together as in the second example above Please ask for more details if I'm not making myself clear enough... EDIT 1: Here's my reasoning for preferring Plus to Add. Consider these two lines of code: list.Add(foo); list.Plus(foo); In my view (and this is a personal thing) the latter is clearly buggy - it's like writing "x + 5;" as a statement on its own. The first line looks like it's okay, until you remember that it's immutable. In fact, the way that the plus operator on its own doesn't mutate its operands is another reason why Plus is my favourite. Without the slight ickiness of operator overloading, it still gives the same connotations, which include (for me) not mutating the operands (or method target in this case). EDIT 2: Reasons for not liking Add. Various answers are effectively: "Go with Add. That's what DateTime does, and String has Replace methods etc which don't make the immutability obvious." I agree - there's precedence here. However, I've seen plenty of people call DateTime.Add or String.Replace and expect mutation. There are loads of newsgroup questions (and probably SO ones if I dig around) which are answered by "You're ignoring the return value of String.Replace; strings are immutable, a new string gets returned." Now, I should reveal a subtlety to the question - the type might not actually be an immutable list, but a different immutable type. In particular, I'm working on a benchmarking framework where you add tests to a suite, and that creates a new suite. It might be obvious that: var list = new ImmutableList<string>(); list.Add("foo"); isn't going to accomplish anything, but it becomes a lot murkier when you change it to: var suite = new TestSuite<string, int>(); suite.Add(x => x.Length); That looks like it should be okay. Whereas this, to me, makes the mistake clearer: var suite = new TestSuite<string, int>(); suite.Plus(x => x.Length); That's just begging to be: var suite = new TestSuite<string, int>().Plus(x => x.Length); Ideally, I would like my users not to have to be told that the test suite is immutable. I want them to fall into the pit of success. This may not be possible, but I'd like to try. I apologise for over-simplifying the original question by talking only about an immutable list type. Not all collections are quite as self-descriptive as ImmutableList<T> :)

    Read the article

  • Immutable classes in C++

    - by ereOn
    Hi, In one of my projects, I have some classes that represent entities that cannot change once created, aka. immutable classes. Example : A class RSAKey that represent a RSA key which only has const methods. There is no point changing the existing instance: if you need another one, you just create one. My objects sometimes are heavy and I enforced the use of smart pointers to avoid copy. So far, I have the following pattern for my classes: class RSAKey : public boost::noncopyable, public boost::enable_shared_from_this<RSAKey> { public: /** * \brief Some factory. * \param member A member value. * \return An instance. */ static boost::shared_ptr<const RSAKey> createFromMember(int member); /** * \brief Get a member. * \return The member. */ int getMember() const; private: /** * \brief Constructor. * \param member A member. */ RSAKey(int member); /** * \brief Member. */ const int m_member; }; So you can only get a pointer (well, a smart pointer) to a const RSAKey. To me, it makes sense, because having a non-const reference to the instance is useless (it only has const methods). Do you guys see any issue regarding this pattern ? Are immutable classes something common in C++ or did I just created a monster ? Thank you for your advices !

    Read the article

  • What to call factory-like (java) methods used with immutable objects

    - by StaxMan
    When creating classes for "immutable objects" immutable meaning that state of instances can not be changed; all fields assigned in constructor) in Java (and similar languages), it is sometimes useful to still allow creation of modified instances. That is, using an instance as base, and creating a new instance that differs by just one property value; other values coming from the base instance. To give a simple example, one could have class like: public class Circle { final double x, y; // location final double radius; public Circle(double x, double y, double r) { this.x = x; this.y = y; this.r = r; } // method for creating a new instance, moved in x-axis by specified amount public Circle withOffset(double deltaX) { return new Circle(x+deltaX, y, radius); } } So: what should method "withOffset" be called? (note: NOT what its name ought to be -- but what is this class of methods called). Technically it is kind of a factory method, but somehow that does not seem quite right to me, since often factories are just given basic properties (and are either static methods, or are not members of the result type but factory type). So I am guessing there should be a better term for such methods. Since these methods can be used to implement "fluent interface", maybe they could be "fluent factory methods"? Better suggestions? EDIT: as suggested by one of answers, java.math.BigDecimal is a good example with its 'add', 'subtract' (etc) methods. Also: I noticed that there's this question (by Jon Skeet no less) that is sort of related (although it asks about specific name for method)

    Read the article

  • Can immutable be a memory hog?

    - by ciscoheat
    Let's say we have a memory-intensive class like an Image, with chainable methods like Resize() and ConvertTo(). If this class is immutable, won't it take a huge amount of memory when I start doing things like i.Resize(500, 800).Rotate(90).ConvertTo(Gif), compared to a mutable one which modifies itself? How to handle a situation like this in a functional language?

    Read the article

  • C#: Immutable view of a list's objects?

    - by Rosarch
    I have a list, and I want to provide read-only access to a collection containing its contents. How can I do this? Something like: public ICollection<Foo> ImmutableViewOfInventory() { IList<Foo> inventory = new List<Foo>(); inventory.add(new Foo()); return inventory.ImmutableView(); } Additionally, an immutable IEnumerable would also be fine.

    Read the article

  • Building big, immutable objects without constructors having long parameter lists

    - by Malax
    Hi StackOverflow! I have some big (more than 3 fields) Objects which 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, 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: "Constructor abominations with long parameter lists" The Builder Pattern Thanks for your input!

    Read the article

  • Building big, immutable objects without using constructors having long parameter lists

    - by Malax
    Hi StackOverflow! I have some big (more than 3 fields) Objects which 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, 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: "Constructor abominations with long parameter lists" The Builder Pattern Thanks for your input!

    Read the article

  • Immutable Dot Net strings

    - by klork
    I usually define my string variables in vb.net as Dim f_sName as string=String.Empty f_sName = "foo" Given the immutable nature of strings in .net, is there a better way to initialize strings and deal with the "Variable 'f_sName ' is used before it has been assigned a value. A null reference exception could result at runtime." warning? Also for classes that do not have constructors which accept no arguments such as System.Net.Sockets.NetworkStream, what is the best way to define and initialize a variable of that type? All comments are highly appreciated. Thanks

    Read the article

  • The best way to assign an immutable instance to a Collection in Java

    - by Ali
    Today I was reading through some Hibernate code and I encounter something interesting. There is a class called CollectionHelper that defines the following constant varibale: public final class CollectionHelper { public static final List EMPTY_LIST = Collections.unmodifiableList( new ArrayList(0 ) ; public static final Collection EMPTY_COLLECTION = Collections.unmodifiableCollection(new ArrayList(0) ); public static final Map EMPTY_MAP = Collections.unmodifiableMap( new HashMap(0) ); They have used these constants to initialize collections with immutable instances. Why they didn't simply use the Collections.EMPTY_LIST for initializing lists? Is there a benefit in using the following method?

    Read the article

  • Would an immutable keyword in Java be a good idea?

    - by berry120
    Generally speaking, the more I use immutable objects in Java the more I'm thinking they're a great idea. They've got lots of advantages from automatically being thread-safe to not needing to worry about cloning or copy constructors. This has got me thinking, would an "immutable" keyword go amiss? Obviously there's the disadvantages with adding another reserved word to the language, and I doubt it will actually happen primarily for the above reason - but ignoring that I can't really see many disadvantages. At present great care has to be taken to make sure objects are immutable, and even then a dodgy javadoc comment claiming a component object is immutable when it's in fact not can wreck the whole thing. There's also the argument that even basic objects like string aren't truly immutable because they're easily vunerable to reflection attacks. If we had an immutable keyword the compiler could surely recursively check and give an iron clad guarantee that all instances of a class were immutable, something that can't presently be done. Especially with concurrency becoming more and more used, I personally think it'd be good to add a keyword to this effect. But are there any disadvantages or implementation details I'm missing that makes this a bad idea?

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >