Skip to main content
Software Engineering

Return to Answer

broken link fixed, cf. https://meta.stackoverflow.com/a/406565/4751173
Source Link
Glorfindel
Glorfindel
  • 3.2k
  • 6
  • 28
  • 34

Sure it is possible. Some even coined a term for it: Popsicle immutablePopsicle immutable. The general idea is to have a mutable data structure on the inside, plus a flag that tells you whether the object is currently mutable or not. Note that in many cases (including this one), you only want the flag to go from "mutable" to "immutable" once, and never the other way. Then you simply add

  1. Methods to mutate the state, which check the flag and raise an error if the object is not mutable.
  2. A method to flip the flag and thus turn the object immutable. This is also a good opportunity to perform some optimizations (e.g. trim excess capacity of collections or build an index) as you now know the state won't change.

This does add some complexity to the implementation, and some potential for errors (forgetting to flip the switch, trying to mutate an immutable object). But that's inherent to this ability. To regain a bit of simplicity, you can disallow operations not related to building the state while the object is mutable. This means you have fewer cases to support/worry about.

Sure it is possible. Some even coined a term for it: Popsicle immutable. The general idea is to have a mutable data structure on the inside, plus a flag that tells you whether the object is currently mutable or not. Note that in many cases (including this one), you only want the flag to go from "mutable" to "immutable" once, and never the other way. Then you simply add

  1. Methods to mutate the state, which check the flag and raise an error if the object is not mutable.
  2. A method to flip the flag and thus turn the object immutable. This is also a good opportunity to perform some optimizations (e.g. trim excess capacity of collections or build an index) as you now know the state won't change.

This does add some complexity to the implementation, and some potential for errors (forgetting to flip the switch, trying to mutate an immutable object). But that's inherent to this ability. To regain a bit of simplicity, you can disallow operations not related to building the state while the object is mutable. This means you have fewer cases to support/worry about.

Sure it is possible. Some even coined a term for it: Popsicle immutable. The general idea is to have a mutable data structure on the inside, plus a flag that tells you whether the object is currently mutable or not. Note that in many cases (including this one), you only want the flag to go from "mutable" to "immutable" once, and never the other way. Then you simply add

  1. Methods to mutate the state, which check the flag and raise an error if the object is not mutable.
  2. A method to flip the flag and thus turn the object immutable. This is also a good opportunity to perform some optimizations (e.g. trim excess capacity of collections or build an index) as you now know the state won't change.

This does add some complexity to the implementation, and some potential for errors (forgetting to flip the switch, trying to mutate an immutable object). But that's inherent to this ability. To regain a bit of simplicity, you can disallow operations not related to building the state while the object is mutable. This means you have fewer cases to support/worry about.

Source Link
user7043
user7043

Sure it is possible. Some even coined a term for it: Popsicle immutable. The general idea is to have a mutable data structure on the inside, plus a flag that tells you whether the object is currently mutable or not. Note that in many cases (including this one), you only want the flag to go from "mutable" to "immutable" once, and never the other way. Then you simply add

  1. Methods to mutate the state, which check the flag and raise an error if the object is not mutable.
  2. A method to flip the flag and thus turn the object immutable. This is also a good opportunity to perform some optimizations (e.g. trim excess capacity of collections or build an index) as you now know the state won't change.

This does add some complexity to the implementation, and some potential for errors (forgetting to flip the switch, trying to mutate an immutable object). But that's inherent to this ability. To regain a bit of simplicity, you can disallow operations not related to building the state while the object is mutable. This means you have fewer cases to support/worry about.