Thu Apr 4 11:22:29 EDT 2019

About state

Some rules of thumb:

- If it can be done without state, do it without state first, because
  that allows more properties to be imposed.

- If that's not possible, try to keep the state short-lived, such that
  at a higer,coarser level there is still a stateless interface.  This
  is often necessary to optimize inner loops.

- If that's not possible, try to ensure that state is really just a
  cache.  I.e. it can be thrown away and rebuilt without loosing
  information.  This is often necessary to optimize distributed
  systems where both ends need a copy of the information.

- What's left are true 'objects', which are a combination of two forms:

  - A database: data on persistent store, possibly indexed and cached
    to make the implementation efficient.

  - Models of physical objects that have physical state variables

Note that herein is contained the idea that "entanglement to
environemnt" is the real problem with object-oriented design.  As long
as all state is local, the distinction between OO and functional
effectively disappears.  The core idea is that:

   "OO is non-local"