An alternative (and recommended) way for developers to get a reference to a `multi_index` instance in order to get access to the appropriate tables in EOSIO persistent state is to call an overloaded static member function `get` in the `multi_index` class which returns a reference to the appropriate `multi_index` instance.
If the `multi_index::get(uint64_t code, uint64_t scope)` overload is called, the function would return a const reference to the appropriate `multi_index` instance, which disallows (at compilation time) use of the `emplace`, `modify`, and `erase` methods which could potentially modify the EOSIO persistent state.
If the `multi_index::get(uint64_t scope)` overload is called, the function would return a reference to the appropriate `multi_index` instance where the `code` was automatically selected to be the current receiver. This overload would be used when the developer wants to have a `multi_index` instance that allows them to modify the EOSIO persistent state, in which case they must be using the current receiver as the `code` anyway because they are not allowed to modify state in other `code`.
With this new interface of getting a reference to the appropriate `multi_index` instance, we can introduce convenient automatic caching of `multi_index` instances so that developers don’t have to do it manually themselves (for example see the [exchange contract](https://github.com/EOSIO/eos/blob/dawn-v3.0.0/contracts/exchange/market_state.hpp#L40-L75)). However, they would still be allowed to implement their own solution if they wish (although it wouldn’t be the recommended path) since they would still be allowed to call the constructor of `multi_index`.