4 ms·
Once created, objects and collections must be immutable. Collections I understand, but what's the point of immutable objects? If you're eschewing mutability, w
by kyllo 12y ago
Once created, objects and collections must be immutable.
Collections I understand, but what's the point of immutable objects? If you're eschewing mutability, why have objects at all? The whole point of objects is to encapsulate mutable state, together with methods for mutating that state.
If you said Once created, data structures must be immutable I would be more inclined to agree.
- sonyandy 12y agoTo "what's the point of immutable objects?": runtime polymorphism + maintaining invariants (since immutable, at the time of construction).
- kyllo 12y agoWhy do you need objects to get runtime polymorphism? Here's a counterexample of runtime polymorphism without objects: http://clojure.org/runtime_polymorphism http://clojure.org/runtime_polymorphism
- tormeh 12y ago>The whole point of objects is to encapsulate mutable state, together with methods for mutating that state. Citation needed. I use my objects to hold immutable state with methods that does not mutate that state.
- kyllo 12y agoWhat do you gain from using objects in that way, as opposed to immutable structs and functions?
- tormeh 12y agoI program in Scala, so structs are not a thing (classes can extend/"inherit" AnyVal to be allocated on the stack, though, I think). Functions are nice, but from a pure syntax standpoint I often prefer methods because it limits the parantheses. It's especially neat when the methods take no arguments, like .toString. But yeah, otherwise there's no difference, really.
- tel 12y agoExpress your immutable objects with an interface like this push : ('a queue, 'a) -> 'a queue pop : 'a queue -> ('a queue, 'a) option In other words, instead of mandating that state updates in objects occurs via global ambient state simply cause objects to return a new version of themselves with the suitable updated state. All your standard immutability tricks now apply. Objects maintain their meaning through their opaqueness/type-abstraction.
- kyllo 12y agosimply cause objects to return a new version of themselves with the suitable updated state That's what Clojure does (and what lots of other functional languages do), only they're not "objects," they're just data structures. Again, if you're not using mutability or inheritance, then why do you need objects at all? What do objects buy you, compared to data types + functions? In the absence of those features, isn't an object class really just a module with a data type definition and some functions in it?
- tel 12y agoIt depends on what "object" means to you. Turns out this is very, very complex. A deep answer has a lot to do with laziness, F-algebras, totality, dependent types, yada yada yada. In particular, the tip of this iceberg is the difficulty of comparing functions for equality. Does any of this matter? Maybe not. Structs with recursion can get you 90% of what you want (just ask OCaml). One thing you might miss is the ability to do late binding and open recursion—up to you whether or not you care.
- kyllo 12y agoOne thing you might miss is the ability to do late binding and open recursion In the absence of objects, that's what `letrec` is for. Scheme, OCaml, and SML all have it. In Haskell `let` is `letrec` by default. Clojure has `letfn`. C has forward declarations. Without these features you wouldn't be able to write mutually recursive functions.