Table of Contents
Objects that can be written, unless they've been read
Dynamic configuration can be a wonderful thing. It can also be a nightmare, if you have configuration values that depend on other configuration values, and you are using lots of components that are reading and writing those values. If you change a value after it has already been used by another component, how can you be sure what objects were configured in what way?
Different languages and systems approach this issue differently. In Java, it's common to have settings which can be set only once. In Python, one may use immutables. Zope 3X has a configuration conflict detection algorithm. But all of these approaches depend on either a write-once approach or an atomic configuration phase.
PEAK takes a "quantum physics" approach to immutability instead: treat configuration data as an opaque box, whose contents you can change at will. However, once somebody looks in the box, the result is fixed and can no longer be changed. You can think of it as a kind of "lazy immutability".
The EigenData module supplies an
FYI: the module and classes are named after eigenstates in quantum physics;
"one of a finite number of states that a quantum system can be in". The
famous "Schrodinger's Cat" thought experiment is an analogy for eigenstates:
once the box is opened, its contents are forced to collapse to a single
Table of ContentsThis document was automatically generated on Mon Apr 15 01:11:19 2019 by HappyDoc version 2.1