Skip to main content
6 events
when toggle format what by license comment
Feb 17 at 4:11 comment added supercat @Bergi: Mutable objectrs to which shared references exist generally have one "owning" entity, whose state encapsulates the state of the object, and other entities which either observe the state, or put data into the entity for the benefit of its owner. In some cases, it may make sense for the owning entity to freeze an entity, but owning vs. non-owning entities add issues which go beyond freezing.
Feb 17 at 2:31 comment added Bergi What about shared references to mutable containers (and unshared references to immutable containers, though those are boring)?
Feb 16 at 23:02 comment added supercat ...it's hard to guard against non-const aliases. Further, while I didn't mention it, recognizing different kinds of references makes it possible for a language to meaningfully supply equality-check and cloning methods, though two of each should be specified, to handle the kinds of references that might be used to identify an object.
Feb 16 at 23:00 comment added supercat @BenVoigt: It's very easy for a language like Java to treat all references the same, but doing that makes it hard to avoid copying objects that will never end up being mutated, or constructing new immutable versions of objects which are about to be discarded. Producing a new "edited" immutable object by making a mutable copy of an object, applying required changes, and freezing it, is much cleaner and easier than trying to having to manually specify every attribute which is supposed to be passed through unchanged, but if the language doesn't recognize "unshareable references"...
Feb 16 at 22:46 comment added Ben Voigt Immediately thought "what happens to existing non-const aliases" and this answer was the only one to recognize the problem.
Feb 15 at 19:03 history answered supercat CC BY-SA 4.0