Replaces the one-big top level deep merge cache with individual deep
merge caches in every container. The Immutable container state becomes
the deep merge cache.
- Does not use a pure decorator style approach since that failed before
because of ruby internals breaking things like `===` and `=~` on
decorated objects, so we inherit (ultimately from Hash + Array).
- The state being the container state is useful in ruby since APIs on
Hash and Array poke around in internal state to make things fast. If
we inherit from Hash/Array but don't have the correct internal state
things go wonky.
- Throwing away the internal state is equivalent to flushing the cache.
- Since we throw away all linked objects when we do that, we flush at
every level below the level being flushed (which is correct semantics).
- If a user has a pointer to an old immutable object from a sub-level,
that isn't mutated so the old object still contains the old view of
the data (which I think is correct, although I have some doubts that
its necessary, but it came along free for the ride).
- When we reset the cache we do mutate the cache being reset, which
might change data in held references. If this becomes an issue the fix would
be to reset the cache at the level above by creating a new, "empty"
ImmutableHash/ImmutableArray object and inserting it into the
deep_merge_cache datastructure instead of clearing the internal state
of the child object. I don't know practically how anyone would hit
this, though, so would prefer to wait on doing that work until we see
an actual bug report.
- Because of the way ruby pokes around internally there's some
weirdnesses like the pre-generation of the cache for all the values of
a subarray when #each is called, which is due to the way that ruby
walks through array-serialized hashes when called like:
`Array#each { key, value| ... }` (which is an undocumented(?) thing
in ruby).
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>